On Sun, Mar 16, 2025 at 12:31 PM Matt Fonda <[email protected]> wrote:
> Hi Daniel,
>
> I believe this feature essentially amounts to "add methods which can never
> be called", which in my mind makes no sense. If a method types against an
> interface, and that interface uses a method with a never parameter type,
> then we cannot actually call that method. We'd need to know the specific
> concrete type, which defeats the purpose of using an interface in the first
> place.
>
First, I would point out that I tried to make this limited to methods that
already cannot be called - only to interfaces and abstract methods. You
already can't call those directly, you need to have a subclass. And you can
always type against the implementation with the actual methods that are not
never-typed.
So I would ask - if not never parameters, then what should users do? It
seems like, for the use case of "the interface adds a method but there are
no promises about what parameters it accepts", the options would otherwise
be
* documenting that the method should exist, and checking for it, but not
adding it to the interface directly so that PHP doesn't complain
* having implementations "accept" parameters that they then manually throw
errors for, c.f. https://3v4l.org/pTdMg
The original inspiration which I discussed in the RFC is fixing the
signature of the BackedEnum methods, which currently use the second option.
>
> See note from Nikita [1] from previous discussion which expands on this
> idea more, and shows that generics is really what we need here.
>
> [1] https://externals.io/message/115712#115719
>
> Best regards,
> --Matthew
>
I agree that generics would be great and really useful, but should that
stop never parameters? There has also been some discussion about generics
on the inner classes RFC thread - should the dream of generics eventually
stand in the way of independently-useful and smaller-scoped features now?
-Daniel