Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127082
Precedence: bulk
MIME-Version: 1.0
References: <CALaXqqRWL8ygMGoA5xnMtt7w6rE-5WJJZ5P9oiO3vHgqvod=Fw@mail.gmail.com>
In-Reply-To: <CALaXqqRWL8ygMGoA5xnMtt7w6rE-5WJJZ5P9oiO3vHgqvod=Fw@mail.gmail.com>
Date: Tue, 8 Apr 2025 18:40:31 -0700
Message-ID: <CALaXqqQEbgsixphmaUPrGENvmPUV0wURDtoXGtT40DwAi60Jpw@mail.gmail.com>
Subject: [PHP-DEV] Re: [RFC] [Discussion] Never parameters
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000002ba95706324e904e"
From: daniel.e.scherzer@gmail.com (Daniel Scherzer)

--0000000000002ba95706324e904e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 10, 2025 at 12:05=E2=80=AFPM Daniel Scherzer <
daniel.e.scherzer@gmail.com> wrote:

> Hi internals,
>
> I'd like to start discussion on a new RFC about allowing `never` for
> parameter types when declaring a method.
>
> * RFC: https://wiki.php.net/rfc/never-parameters-v2
> * Implementation: https://github.com/php/php-src/pull/18016
>
> -Daniel
>


Since a lot of the discussion seems to be around static analysis and
whether there is a real use case for this, I wanted to share another use
case I just came across: in the `thephpleague/commonmark` package,
different renderers are added to render different types (subclasses) of
`League\CommonMark\Node\Node`. You can see the interface for renderers at
[1]. The overall interface supports being called with any `Node` type, but
each underlying renderer expects to be called with a *narrower* type than
that. To avoid LSP violations, the renderers

* have a `Node` typehint
* have a documentation comment with the actual subclass of `Node` that they
support
* manually throw an exception on invalid values

See, e.g., the default renderer for paragraphs[2]. This seems like exactly
the place where you would find it useful to have `never` parameters. The
current implementation
* uses comments and static analysis tools to document the restriction
* manually throws an exception when violated

Whereas if the base class had a `never` parameter, it could
* use language typehints to document the restriction
* have the exception enforced automatically

I don't think we should be worried about the fact that, under static
analysis, we don't know what type of value is accepted for a `never`
parameter, because under actual operation, you can always just manually
throw an exception for a type you don't want, like commonmark does.

-Daniel

[1]
https://github.com/thephpleague/commonmark/blob/2.6/src/Renderer/NodeRender=
erInterface.php
[2]
https://github.com/thephpleague/commonmark/blob/2.6/src/Renderer/Block/Para=
graphRenderer.php

--0000000000002ba95706324e904e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Mar 10, 2025 at 12:05=E2=80=AFPM =
Daniel Scherzer &lt;<a href=3D"mailto:daniel.e.scherzer@gmail.com">daniel.e=
.scherzer@gmail.com</a>&gt; wrote:</div><div class=3D"gmail_quote gmail_quo=
te_container"><blockquote class=3D"gmail_quote" style=3D"margin:0px 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&#39;d like to start discussion on =
a new RFC about allowing `never` for parameter types when declaring a metho=
d.</div><div><br></div><div>* RFC:=C2=A0<a href=3D"https://wiki.php.net/rfc=
/never-parameters-v2" target=3D"_blank">https://wiki.php.net/rfc/never-para=
meters-v2</a></div><div>* Implementation:=C2=A0<a href=3D"https://github.co=
m/php/php-src/pull/18016" target=3D"_blank">https://github.com/php/php-src/=
pull/18016</a></div><div><br></div><div>-Daniel</div></div></blockquote><di=
v><br></div><div><br></div><div>Since a lot of the discussion seems to be a=
round static analysis and whether there is a real use case for this, I want=
ed to share another use case I just came across: in the `thephpleague/commo=
nmark` package, different renderers are added to render different types (su=
bclasses) of `League\CommonMark\Node\Node`. You can see the interface for r=
enderers at [1]. The overall interface supports=C2=A0being called with any =
`Node` type, but each underlying renderer expects to be called with a <i>na=
rrower</i>=C2=A0type than that. To avoid LSP violations, the renderers</div=
><div><br></div><div>* have a `Node` typehint</div><div>* have a documentat=
ion comment with the actual subclass of `Node` that they support</div><div>=
* manually throw an exception on invalid values</div><div><br></div><div>Se=
e, e.g., the default renderer for paragraphs[2]. This seems like exactly th=
e place where you would find it useful to have `never` parameters. The curr=
ent implementation</div><div>* uses comments and static analysis tools to d=
ocument the restriction</div><div>* manually throws an exception when viola=
ted</div><div><br></div><div>Whereas if the base class had a `never` parame=
ter, it could</div><div>* use language typehints to document the restrictio=
n</div><div>* have the exception enforced automatically</div><div><br></div=
><div>I don&#39;t think we should be worried about the fact that, under sta=
tic analysis, we don&#39;t know what type of value is accepted for a `never=
` parameter, because under actual operation, you can always just manually t=
hrow an exception for a type you don&#39;t want, like commonmark does.</div=
><div><br></div><div>-Daniel</div><div><br></div><div>[1]=C2=A0<a href=3D"h=
ttps://github.com/thephpleague/commonmark/blob/2.6/src/Renderer/NodeRendere=
rInterface.php">https://github.com/thephpleague/commonmark/blob/2.6/src/Ren=
derer/NodeRendererInterface.php</a></div><div>[2]=C2=A0<a href=3D"https://g=
ithub.com/thephpleague/commonmark/blob/2.6/src/Renderer/Block/ParagraphRend=
erer.php">https://github.com/thephpleague/commonmark/blob/2.6/src/Renderer/=
Block/ParagraphRenderer.php</a></div></div></div>

--0000000000002ba95706324e904e--