On Wed, 3 Jun 2020 at 12:32, Nikita Popov <nikita....@gmail.com> wrote:
> 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. > Ok, so let's allow that as well. I'll cover that with tests. > > 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. > Ok, let me see if I understood it: so if someone creates a public function __set($name, $value) {} we would automatically convert (as per this RFC) to public function(string $name, mixed $value): void {} internally, right? Isn't this a BC if someone is returning something inside that method? Or no, are you talking that we only convert that for Reflection purpose? > > Nikita >
