Re: [RFC] Parameter No Type Variance

> > The RFC is a bit lacking in motivation ... > > The main practical use-case I see for this is post-hoc addition of > type-hints on an interface. To cite a particular example we ran into for > PHP 7.0: Derick added a DateTimeZone type hint for the third arg of the > DateTime::createFromFormat() method [1]. The method is already documented > to accept only this class in the manual, but the typehint is not actually > present in the implementation. > > However, this change had to be reverted, because all classes extending > DateTime currently don't have this typehint (and adding it would be illegal > under LSP), so they started throwing a method signature mismatch warning. > > Allowing extending classes to drop typehints in accordance with > variance-rules allow people to add additional parameter typehints on parent > classes without breaking BC. (Adding an additional return typehint would > break BC, but it is still a cross-version compatible change, as consumers > have the possibility of writing code that is valid under both versions -- > something that is currently impossible if you want to add parameter > typehints.) > You're completely right, I'll add that before I start the vote. I think it makes sense to defer the vote into the next year, we still have plenty of time then. Regards, Niklas