On Sun, Aug 11, 2019 at 3:01 PM Sara Golemon <poll...@php.net> wrote:
> On Sun, Aug 11, 2019 at 7:51 AM Nikita Popov <nikita....@gmail.com> wrote: > >> On Sun, Aug 11, 2019 at 2:37 PM Sara Golemon <poll...@php.net> wrote: >> > P.S. - Perhaps a way to the middle might be to introduce implicit return >> > type hints. If a child method is implemented with no return type >> specified >> > on a parent method which has one, then the parent's type is assumed at >> bind >> > time, then we provide a better runtime error if that assumption is >> violated >> > in a strict_types=1 context which is the only place where strict >> covariance >> > of return types matters to PHP. >> > >> >> This is an interesting idea. There's still a BC break here, but it's more >> limited and only applies to code that is actively violating type contracts >> (that were previously implicit). Imho this should not be bound to >> strict_types though: strict_types controls coercion behavior of scalar >> type >> annotations, and nothing else. It should not be overloaded with this >> additional meaning (and I don't think the BC break is nowhere near large >> enough to justify this overloading). >> >> Fair. Just trying to tread as light as possible, but there is a > vanishing point. > > >> Do you have this in mind as something for use by internal classes only, or >> as a general language feature? I can see the use as a general language >> feature (see for example the debacle where PHPUnit added "void" >> annotations >> to some methods). The migration problem of adding return types is >> certainly >> not limited to internal classes. On the other hand it does seem somewhat >> weird that an (inherited) return type will be enforced that was not >> explicitly given in the source. >> >> I agree that it would be as useful to userspace classes as internal > ones. It would allow library authors to embrace strong typing without > breaking consumers who are already conforming to docblock types. > > It's probably worth proof-of-concepting this and making an RFC > irrespective of the push to annotate all the things. If feasible and > accepted, I'd be much more on board with including return types for > internal methods in that plan however. > After thinking about this a bit, this is going to be pretty hard to implement. Currently return type checks are performed using a separate opcode, which means that we need to know the return type at compile-time. At the point where inheritance happens and we know the parent return type, we are no longer able to modify the opcodes of the function. We'd have to integrate the return type check into the main return logic, with a possible negative impact on performance... Nikita
