> > The feature, as implemented, will allow accidental omission of type-hints, > > will it not? > > Yes, correct.
So this breaks the expected behavior of interfaces. This will be harmful to everyone, but especially harmful to new programmers, who may never even learn how to correctly implement an interface, since now they don't have to. Promising to address this in a future version isn't helpful, as that would be a BC break, which rarely anyone condones, even for major releases - changing it now isn't a BC break, so it's easy, but fixing it will be a BC break, which will be very hard to push through. Addressing this by allowing developers to opt-in to proper interface validation in strict mode isn't helpful either, and especially not to new programmers who are likely much farther from learning about strict mode than they are from learning about basic things like properly implementing an interface - and much, much further from learning about parameter type-hint widening. IMO, this is likely to become another one of those historically bad design decisions that were made in spite of everything we know about other programming languages :-( On Tue, May 23, 2017 at 10:46 PM, Niklas Keller <m...@kelunik.com> wrote: > Hi Rasmus, > > >> This parameter type widening RFC, I didn't know about, but I have a >> remark. >> >> The feature, as implemented, will allow accidental omission of type-hints, >> will it not? >> > > Yes, correct. > > >> Previously, the implements keyword guaranteed a correctly type-hinted >> implementation - it's now possible to (purposefully, obviously, in certain >> rare cases) omit type-hints by accident, making the implements keyword >> much >> less (or not any) of a guarantee that the interface is implemented >> correctly. >> > > The interface will just work correctly, what's the actual problem you're > seeing? > > >> The addition of an explicit "mixed" or "any" pseudo-type would have made >> this possible, without losing the guarantee that the implements keyword >> used to provide - that is, it would have been possible to have this >> feature >> for the few cases where it's useful, without affecting safety in the >> majority of other cases where it's not. >> >> I feel like this feature takes a pretty dangerous shortcut by simply >> removing a constraint check that we used to have - in favor of supporting >> a >> few rare cases, we removed a guarantee that interfaces and the >> implements-keyword has always provided. >> >> Those rare cases could have been supported in a safe manner by introducing >> a "mixed" or "any" type, which would have made the use of this feature >> explicit - which would have removed the risk of accidental omission of >> type-hints in the majority of cases. >> > > Unfortunately, that doesn't work for the second (maybe even primary) use > case of the RFC: Adding types to a class isn't a BC break anymore with the > RFC, as child classes will just widen the type and need explicit checks as > before. Without the RFC or with a version with "mixed" or "any", method > signatures will be incompatible again and thus be a BC break when adding > types to the base class. > > "mixed" has been mentioned in the original discussion, but there was not a > lot of interest and mostly explicit disinterest. > > >> The RFC page doesn't link to any discussion, and the Github thread was >> shut >> down after some negative remarks. >> >> I didn't see a discussion or a vote here on internals - did I miss >> something? Where or how did this get discussed and passed? Are these >> discussions happening somewhere else besides internals now? > > > - Original discussion: https://externals.io/thread/505 > - Vote announcement: https://externals.io/thread/613 > - Vote resumption after internals having issues: https://externals.io/ > thread/619 > > Regards, Niklas >
