On Sun, Mar 16, 2025 at 12:31 PM Matt Fonda <matthewfo...@gmail.com> 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
