Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127160
Precedence: bulk
MIME-Version: 1.0
References: <CALaXqqReh_8iAg6O2V=PFfgo1ajzroArYwt_o+7wGif4C4sCTg@mail.gmail.com>
In-Reply-To: <CALaXqqReh_8iAg6O2V=PFfgo1ajzroArYwt_o+7wGif4C4sCTg@mail.gmail.com>
Date: Tue, 22 Apr 2025 10:43:46 +0200
Message-ID: <CADyq6sKiWDKQsoEE5pF6930Ubosk5SQcn_KOQwd2QQc88PcadA@mail.gmail.com>
Subject: Re: [PHP-DEV] [VOTE] Never parameters (v2)
To: Daniel Scherzer <daniel.e.scherzer@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004f0f0e063359fcd7"
From: ocramius@gmail.com (Marco Pivetta)

--0000000000004f0f0e063359fcd7
Content-Type: text/plain; charset="UTF-8"

Hey Daniel,

I'm currently planning to vote "no" on this.


The reason is that I see this RFC as very narrowly scoped on constructors /
named constructors, and only in the case where a concrete class is
referenced by a consumer.
Constructors/named constructors are effectively not part of an object's
signature, but are rather functions attached to a namespace.


One could argue that `BackedEnum::from()` and `BackedEnum::tryFrom()`
should never have been interfaced anyway: a consumer relies on the concrete
class here anyway.


At the moment, I don't see how a `never` parameter would be used on an
instance method.


I also disagree with the "Userland example" section (`CommonMark`) where
narrower parameter types would be used on concrete implementations of an
interface, hence breaking LSP anyway, if one refers to the parent type in
their code.
The current `CommonMark` "add a runtime assertion" approach is IMO
sufficient, and this RFC doesn't seem to improve the situation, effectively
swapping an assertion failure with a `TypeError`.
An example involving PHPStan and Psalm (and showing a sound implementation
with generic types) would go a long way.
Something that shows how to efficiently use `never` on an instance method,
and have the entire thing type-check in PHPStan / Psalm would really help:
perhaps even the `CommonMark` bit.



Marco Pivetta

https://mastodon.social/@ocramius

https://ocramius.github.io/


On Mon, 21 Apr 2025 at 22:16, Daniel Scherzer <daniel.e.scherzer@gmail.com>
wrote:

> Hi internals,
>
> I have opened the vote on https://wiki.php.net/rfc/never-parameters-v2.
> The vote will run for 2 weeks (and a few hours), closing on May 5th at the
> end of the day (UTC).
>
> --Daniel
>

--0000000000004f0f0e063359fcd7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hey Daniel,</div><div><br></div><div>I&#39;m currentl=
y planning to vote &quot;no&quot; on this.</div><div><br></div><div><br></d=
iv><div>The reason is that I see this RFC as very narrowly scoped on constr=
uctors / named constructors, and only in the case where a concrete class is=
 referenced by a consumer.</div><div>Constructors/named constructors are ef=
fectively not part of an object&#39;s signature, but are rather functions a=
ttached to a namespace.</div><div><br></div><div><br></div><div>One could a=
rgue that `BackedEnum::from()` and `BackedEnum::tryFrom()` should never hav=
e been interfaced anyway: a consumer relies on the concrete class here anyw=
ay.</div><div><br></div><div><br></div><div>At the moment, I don&#39;t see =
how a `never` parameter would be used on an instance method.</div><div><br>=
</div><div><br></div><div>I also disagree with the &quot;Userland example&q=
uot; section (`CommonMark`) where narrower parameter types would be used on=
 concrete implementations of an interface, hence breaking LSP anyway, if on=
e refers to the parent type in their code.</div><div>The current `CommonMar=
k` &quot;add a runtime assertion&quot; approach is IMO sufficient, and this=
 RFC doesn&#39;t seem to improve the situation, effectively swapping an ass=
ertion failure with a `TypeError`.</div><div>An example involving PHPStan a=
nd Psalm (and showing a sound implementation with generic types) would go a=
 long way.</div><div>Something that shows how to efficiently use `never` on=
 an instance method, and have the entire thing type-check in PHPStan / Psal=
m would really help: perhaps even the `CommonMark` bit.</div><div><br></div=
><div><br> </div><div><br></div><div><div dir=3D"ltr" class=3D"gmail_signat=
ure" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">Marco Pivetta <br>=
<br><a href=3D"https://mastodon.social/@ocramius" target=3D"_blank">https:/=
/mastodon.social/@ocramius</a><br><br><a href=3D"https://ocramius.github.io=
/" target=3D"_blank">https://ocramius.github.io/</a><br></div></div></div><=
br></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"l=
tr" class=3D"gmail_attr">On Mon, 21 Apr 2025 at 22:16, Daniel Scherzer &lt;=
<a href=3D"mailto:daniel.e.scherzer@gmail.com">daniel.e.scherzer@gmail.com<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr">Hi internals,<div><br></div><div>I have opened the vote on=
=C2=A0<a href=3D"https://wiki.php.net/rfc/never-parameters-v2" target=3D"_b=
lank">https://wiki.php.net/rfc/never-parameters-v2</a>. The vote will run f=
or 2 weeks (and a few hours), closing on May 5th at the end of the day (UTC=
).</div><div><br></div><div>--Daniel</div></div>
</blockquote></div>

--0000000000004f0f0e063359fcd7--