On Sat, 14 Aug 2021 at 16:01, AllenJB <php.li...@allenjb.me.uk> wrote:
> This RFC only considers this feature for arguments. Why is it also not a > valid feature for return types? I think it might be useful for abstract > classes and interfaces (for example, the Iterator interface) to force > implementers to specify a return type for certain methods whilst not > specifying anything about it themselves. > You can already do this since PHP 7.4, because return types are co-variant. Any implementor can add a return type to specify what they return, as mixed is the top type. This RFC is not about "forcing" X to declare a type, it is to allow variance changes which cannot currently be done (well except adding a dummy argument type of bool that you can widen to something more general and just need to check the case is not bool but that's also hackery). This feature is for sure an edge case and not a replacement for generics, but the main motivation I see is to be useful for engine hooks like a Equatable/Ordable comparison overload or more general operator overloading, where if the object doesn't specify it's capability it is like it "implements" the magic method (or whatever it comes to be) with an argument type of "never" which results in a TypeError meaning it does not support this operation. Maybe it does not make sense to make this available for userland, but I do think it is somewhat necessary for these sorts of features to have this concept. Best regards, George P. Banyard
