Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126972
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 28 Mar 2025 21:45:58 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <b68d97a8-aa76-4b36-b0d0-c14009f3d9f5@app.fastmail.com>
In-Reply-To: 
 <CAJF_ukXGj4OtAKza6D-nANL2H+4=MMWMZXCpTKD_vsWJZ6-CkQ@mail.gmail.com>
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>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Never parameters
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Mar 28, 2025, at 3:42 PM, Matt Fonda wrote:
> Hi Tim and Larry,
>
> Thanks for sharing examples. I'm not sure I follow how never parameter=
s=20
> help in either of these cases. As far as I can tell, the problem=20
> remains that these methods can't actually be called.

> I share Nikita's sentiment in the previous RFC discussion [1], and hav=
e=20
> yet to see an answer to it:
>
>> I don't think this really addresses my concern, so let me repeat it: =
You
>> cannot actually call a method using a never-type argument while typing
>> against the interface. What's the point of the interface then?
>>=20
>> I don't think "you must use this in conjunction with a 3rd-party phpd=
oc
>> generics implementation for it to make any sense at all" is a suitabl=
e way
>> to resolve that.
>
> On Fri, Mar 21, 2025 at 8:53=E2=80=AFAM Larry Garfield <larry@garfield=
tech.com> wrote:
>> Changing the interface to use `never` instead of `mixed` would have t=
he weakest guarantees of the three, since it doesn't force me to use the=
 *same* widened type on serializeInt(), serializeFloat(), serializeStrin=
g(), etc., even though it would always be the same.  But it would allow =
me to communicate more type information than I can now.
>
> Suppose you made this change from mixed to never. As long as you're=20
> typing against the Formatter interface and not a specific=20
> implementation, then you cannot actually call=20
> $formatter->serializeInt() etc. because the interface defines the=20
> parameter type as never, and you cannot call a method with a parameter=20
> type of never.
>
> This is the case in your real world usage [1]. Here,=20
> $serializer->formatter is typed against Formatter [2], not a specific=20
> implementation. As such, all we know is that we have an instance of=20
> Formatter--we don't know anything about the concrete type--and thus we=20
> can't actually call e.g. serializeInt() because never is the only type=20
> we know here.

I have to think people are misunderstanding Nikita's earlier comment, or=
 perhaps that he phrased it poorly. =20

The determination of whether a method call is type-compatible with the p=
arameters 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 b=
een 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 tha=
n the interface.

The idea of a never typed parameter is exactly the same: It starts off s=
uper-narrow (accepts nothing), so implementations can accept anything wi=
der than "nothing" and still be type compatible.  You *can* call it.

What you cannot do is determine *statically* that it is callable, becaus=
e at static-analysis time, all you know is the interface.  So SA tools w=
on'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 agai=
nst it 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 so=
me weird engine limitation that I don't know about.

In fairness, though, it seems to me that Associated Types would have the=
 same SA issue.  It would probably be more evident for them that they ca=
nnot try to enforce the type statically, but I don't know how they could=
 do a better job of reporting it than with a never type.  (Someone else =
who understands Associated Types better than I, how would that work?)

--Larry Garfield