On Mon, Mar 10, 2025 at 12:05 PM Daniel Scherzer < daniel.e.scher...@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/NodeRendererInterface.php [2] https://github.com/thephpleague/commonmark/blob/2.6/src/Renderer/Block/ParagraphRenderer.php
