On Sun, May 31, 2020 at 11:20 PM Gabriel Caruso <carusogabrie...@gmail.com> wrote:
> On Sun, 31 May 2020 at 15:57, Nikita Popov <nikita....@gmail.com> wrote: > >> On Fri, May 29, 2020 at 6:45 PM Gabriel Caruso <carusogabrie...@gmail.com> >> wrote: >> >>> Hello, internals! >>> >>> I have opened the voting for >>> https://wiki.php.net/rfc/magic-methods-signature. >>> >>> The voting period ends on 2020-06-19 at 18h (CEST). >>> >> >> The RFC is a bit unclear on what is actually being proposed. It says >> >> > This RFC proposes to add parameter and return types checks per the >> following details. >> >> and goes on to list (reasonable looking) magic method signatures, but >> does not say how exactly those types are going to be checked. Is this going >> to require exactly the same signature, or is this going to be in accordance >> with variance rules? For example, are all of the following signatures valid >> under this RFC? Only the first two? None of them? >> >> // Narrowed return type from ?array >> public function __debugInfo(): array {} >> >> // Narrowed return type from mixed >> public function __get(string $name): int {] >> >> // Widened argument type from string >> public function __get(string|array $name): mixed {} >> > > > They are going to be checked following the variance rules, not the > *exactly* same as the RFC. I'll mention this, thanks for point it out. > > Assuming this, your examples: > > 1 and 2. Will be valid, following the rules introduced by the `mixed` RFC. > > 3. Is that allowed in PHP? If so, the RFC will compliance with that. > Yes, it is allowed. It makes little sense in this particular case, but it's allowed. Also, is omitting the return type still permitted, even though it would >> nominally violate variance? >> >> public function __debugInfo() {} >> > > Yes, this hasn't changed. The RFC only affects *typed* methods. > >> Finally, if omitting the return type is permitted, will an implicit >> return type be added, like we do for __toString()? Would the method >> automatically become >> >> public function __debugInfo(): ?array {} >> > > An implicit return type won't be added for any of the magic methods. I > believe that's a huge BC, and I don't want to debate that for PHP 8 (maybe > PHP 9, yes). > Why would this be a BC break? To make sure we're on the same page, I'm suggesting to do the same as we do for __toString(), where if you declare public function __toString() {} we automatically convert it into public function __toString(): string {} internally. We could do the same for all other magic methods, and I don't think it would introduce a particularly severe BC break. We did this for __toString() to work with the Stringable interface, and we don't have the same requirement for other magic methods, but I still think it's worth considering this for consistency reasons. Nikita
