Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110349
MIME-Version: 1.0
References: <CAP=4hCKgwc9_Q6NtVnHajc3HAsHATPvLH-MLAKSQP=m+xP2yEg@mail.gmail.com>
 <CAF+90c-S8xBwL04GgaS1dLQEEdeG4Kx2h7iYiJrstcEK22m9hg@mail.gmail.com> <CAP=4hCJg595KnHdgDv5m__RYqKnTCRyW+zJfJWR9hhY_+1b4-w@mail.gmail.com>
In-Reply-To: <CAP=4hCJg595KnHdgDv5m__RYqKnTCRyW+zJfJWR9hhY_+1b4-w@mail.gmail.com>
Date: Wed, 3 Jun 2020 12:32:41 +0200
Message-ID: <CAF+90c_0N1sBn-LjDxeRUbF6=0MT6kUCoDpd+gzm=8Vh445yUA@mail.gmail.com>
To: Gabriel Caruso <carusogabriel34@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003330e305a72b8d4b"
Subject: Re: [PHP-DEV] [VOTE] Ensure correct signatures of magic methods
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000003330e305a72b8d4b
Content-Type: text/plain; charset="UTF-8"

On Sun, May 31, 2020 at 11:20 PM Gabriel Caruso <carusogabriel34@gmail.com>
wrote:

> On Sun, 31 May 2020 at 15:57, Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> On Fri, May 29, 2020 at 6:45 PM Gabriel Caruso <carusogabriel34@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

--0000000000003330e305a72b8d4b--