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.scher...@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 >
