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
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
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
On Mon, Apr 21, 2025 at 1:13 PM 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
This RFC closed with a vote of 3-23 against, the feature is declined.
-Daniel