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