Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126986
Precedence: bulk
MIME-Version: 1.0
References: <CALaXqqRWL8ygMGoA5xnMtt7w6rE-5WJJZ5P9oiO3vHgqvod=Fw@mail.gmail.com>
 <CAJF_ukXsyh9k+JTOiuJvYJ5Brq41vYBb-8+Cg6rfH9yE459Pbg@mail.gmail.com>
 <CALaXqqQDMKju=TmSR4hruG1dr4qb4MTKrmcyQdXqGa2j5B_joQ@mail.gmail.com>
 <CAJF_ukVCV-rP7XfK7BCWkb28M4DPAdWCF-J5_WAHhfP6SPS3oA@mail.gmail.com>
 <ab983707b9845d5288305017205f27a1@bastelstu.be> <CAJF_ukXGj4OtAKza6D-nANL2H+4=MMWMZXCpTKD_vsWJZ6-CkQ@mail.gmail.com>
 <b68d97a8-aa76-4b36-b0d0-c14009f3d9f5@app.fastmail.com>
In-Reply-To: <b68d97a8-aa76-4b36-b0d0-c14009f3d9f5@app.fastmail.com>
Date: Mon, 31 Mar 2025 14:25:06 -0700
Message-ID: <CAJF_ukWXAJcjRdJ9=F1ZzH6Ys-ma74AZbaou8W37ZQ4P-ZOLfA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Never parameters
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006d24710631aa0f1e"
From: matthewfonda@gmail.com (Matt Fonda)

--0000000000006d24710631aa0f1e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Larry,

On Fri, Mar 28, 2025 at 7:48=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com>
wrote:

> I have to think people are misunderstanding Nikita's earlier comment, or
> perhaps that he phrased it poorly.
>
> The determination of whether a method call is type-compatible with the
> parameters passed to it is made *at runtime*, on the class.  You can wide=
n
> a parameter type in an implementing class, and it will work.  That's been
> the case since PHP 7.4.
>
> For example: https://3v4l.org/5YPdg
>
> Even though the function is typed against I, if it's passed a C, you can
> call it with a string.  That's because C::a()'s param type is wider than
> the interface.
>
> The idea of a never typed parameter is exactly the same: It starts off
> super-narrow (accepts nothing), so implementations can accept anything
> wider than "nothing" and still be type compatible.  You *can* call it.
>
> What you cannot do is determine *statically* that it is callable, because
> at static-analysis time, all you know is the interface.  So SA tools won'=
t
> be able to verify that anything is valid for that interface.  That's a
> valid criticism of never params, I agree.  Is it enough to vote against i=
t
> on those grounds?  That's up to each voter to decide.
>
> But "you cannot ever even call it" is simply not true, unless there's som=
e
> weird engine limitation that I don't know about.
>

Correct, in saying you can't call it, we're referring to a static analysis
perspective--or phrased differently, a "this is why interfaces exist and
how you correctly use them" perspective. If we're writing code against an
interface, the only thing we're "allowed" to do with a method is exactly
what the interface specifies. If the interface specifies we can never call
a method, then we can... never call it. In other words, we can't write code
against the interface, so what's the point of the interface? It doesn't
provide any extra safety. In fact, quite the opposite. Any code written
against a method with a `never` parameter is inherently unsafe--it only
works if we happen to pass the correct types at runtime.

Widening from something (as opposed to widening from nothing, i.e. `never`)
to something wider (e.g. `int` to `int|string` in your example) makes sense
in a way that widening `never` does not. In this case, you have an actual
type to begin with, so you can still write code against the interface.
Continuing your example, if we're writing code against I::a(), the only
thing we're "allowed" to do with it is call it with an int (otherwise the
code may fail at runtime, e.g. https://3v4l.org/WUTv4). However, being able
to widen here is still useful, because we can _also_ write code against
C::a(), and in that context we're allowed to call with an int or a string.
See https://3v4l.org/qMZOH.

Contrast this to never parameters, where we were never able to write code
against the interface.

I'd argue that this is certainly grounds to vote against it--there's no
point in using an interface if we can't write code against it.

Best regards,
--Matthew

--0000000000006d24710631aa0f1e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div>Hi=
 Larry,</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Fri, Mar 28, 2025 at 7:48=E2=80=AFPM Larry Garfield &lt;<a href=
=3D"mailto:larry@garfieldtech.com" target=3D"_blank">larry@garfieldtech.com=
</a>&gt; wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I have to think people are misunderstanding Nikita&#39;s earlier comment, o=
r perhaps that he phrased it poorly.=C2=A0 <br>
<br>
The determination of whether a method call is type-compatible with the para=
meters passed to it is made *at runtime*, on the class.=C2=A0 You can widen=
 a parameter type in an implementing class, and it will work.=C2=A0 That=
9;s been the case since PHP 7.4.<br>
<br>
For example: <a href=3D"https://3v4l.org/5YPdg" rel=3D"noreferrer" target=
=3D"_blank">https://3v4l.org/5YPdg</a><br>
<br>
Even though the function is typed against I, if it&#39;s passed a C, you ca=
n call it with a string.=C2=A0 That&#39;s because C::a()&#39;s param type i=
s wider than the interface.<br>
<br>
The idea of a never typed parameter is exactly the same: It starts off supe=
r-narrow (accepts nothing), so implementations can accept anything wider th=
an &quot;nothing&quot; and still be type compatible.=C2=A0 You *can* call i=
t.<br>
<br>
What you cannot do is determine *statically* that it is callable, because a=
t static-analysis time, all you know is the interface.=C2=A0 So SA tools wo=
n&#39;t be able to verify that anything is valid for that interface.=C2=A0 =
That&#39;s a valid criticism of never params, I agree.=C2=A0 Is it enough t=
o vote against it on those grounds?=C2=A0 That&#39;s up to each voter to de=
cide.<br>
<br>
But &quot;you cannot ever even call it&quot; is simply not true, unless the=
re&#39;s some weird engine limitation that I don&#39;t know about.<br></blo=
ckquote><div><br></div><div>Correct, in saying you can&#39;t call it, we=
9;re referring=C2=A0to a static analysis perspective--or phrased differentl=
y, a &quot;this is why interfaces exist and how you correctly use them&quot=
; perspective. If we&#39;re writing code against an interface, the only thi=
ng we&#39;re &quot;allowed&quot; to=C2=A0do with a method is exactly what t=
he interface specifies. If the interface specifies we can never call a meth=
od,=C2=A0then we can... never call it. In other=C2=A0words, we can&#39;t wr=
ite code against the interface, so what&#39;s the point of the interface? I=
t doesn&#39;t provide any extra safety. In fact, quite the opposite. Any co=
de written against a method with a `never` parameter is inherently unsafe--=
it only works if we happen to pass the correct types at runtime.</div><div>=
<br></div><div>Widening from something (as opposed to widening from nothing=
, i.e. `never`) to something wider (e.g. `int` to `int|string` in your exam=
ple) makes sense in a way that widening `never` does not. In this case, you=
 have an actual type to begin with, so you can still write code against the=
 interface. Continuing your example, if we&#39;re writing code against I::a=
(), the only thing we&#39;re &quot;allowed&quot; to do with it is call it w=
ith an int (otherwise the code may fail at runtime, e.g.=C2=A0<a href=3D"ht=
tps://3v4l.org/WUTv4" target=3D"_blank">https://3v4l.org/WUTv4</a>). Howeve=
r, being able to widen here is still useful, because we can _also_ write co=
de against C::a(), and in that context we&#39;re allowed to call with an in=
t or a string. See <a href=3D"https://3v4l.org/qMZOH" target=3D"_blank">htt=
ps://3v4l.org/qMZOH</a>.</div><div><br></div><div>Contrast this to never pa=
rameters, where we were never able to write code against the interface.</di=
v><div><br></div><div>I&#39;d argue that this is certainly grounds to vote =
against it--there&#39;s no point in using an interface if we can&#39;t writ=
e code against it.</div><div><br></div><div>Best regards,</div><div>--Matth=
ew</div><div><br></div></div></div>
</div>
</div>
</div>

--0000000000006d24710631aa0f1e--