Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113990
MIME-Version: 1.0
References: <CAH5C8xUqzFJ4V0uo7_FviMq3Sy9Da3MWNMhh+neMO8ZjEnyQWg@mail.gmail.com>
 <B4EABD3F-34C0-495C-8FD0-4646E52C0278@gmail.com> <CAH5C8xXa=ABqCUS+91HvJV=p_q0k00eSjz0uDfqo-5tHhBN5Vg@mail.gmail.com>
 <CAOWwgp=Ado67nQphK0NQ9E=TVvhq8cCSyCog3rhXFTuPNZ+m2w@mail.gmail.com>
 <CAH5C8xXkLZ1weGSZr_VFbRO1gSKZ3CTR9qBE-Z9U_QJXCJDKOA@mail.gmail.com>
 <CAH5C8xV1AixN=a_d3NCcWk9-01Tr5=nCwxQP9kgwvEPKJvgung@mail.gmail.com>
 <CAOWwgp=5P98umLMjof5QM6CbKqr8+nE7nvE0MCfykq+AzJizOg@mail.gmail.com> <CAH5C8xWKz1TSGrJNDBJokds68Dqp--3oHOb4=fVOA5DA=b1BJg@mail.gmail.com>
In-Reply-To: <CAH5C8xWKz1TSGrJNDBJokds68Dqp--3oHOb4=fVOA5DA=b1BJg@mail.gmail.com>
Date: Wed, 7 Apr 2021 19:01:08 +0200
Message-ID: <CAOWwgpmtzuKL0yo1vhVw+yjt=KcUBokWpBW9tLm_3jP=0=royg@mail.gmail.com>
To: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000056dd5a05bf64e197"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Adding return types to internal methods
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--00000000000056dd5a05bf64e197
Content-Type: text/plain; charset="UTF-8"

> For userland, there are already ways to declare the planned return type
>> (aka @return in phpdoc), so we might not need any new way to declare this
>> from the engine pov.
>>
>
> Yes, I think I agree, but I'd be curious about Nikita's opinion as well,
> since he brought up this problem first.
>
>
>> We should replace the SuppressReturnTypeNotice by the TentativeReturnType
>> one right away.
>
> The TentativeReturnType would mean: "I'm going to add a return type to
>> this method in its next major".
>> As a consequence, for child classes of internal methods, this would
>> suppress the notice.
>>
>
> If we get rid of the userland part of my proposal, then I think we can
> really rename SuppressReturnTypeNotice
> to TentativeReturnType.
>

This would mean that the RFC could describe how userland (code analyzers)
should understand the TentativeReturnType when encountering one, without
asking anything from the engine when base userland classes are extended.
For internal classes, the attribute would just mean what you wrote already.
That'd be fine to me.


> As a corollary, adding this attribute should conflict with having a real
>> return type.
>
>
> This is the only questionable part for me, because then this RFC would
> cause more trouble for overriding methods
> which already define a wrong return type: a deprecation notice would
> always be triggered for them on PHP 8.1+
> until return types are fixed or removed. And as we discussed it
> previously, fixing them is not always possible.
> Or is there any specific reason I'm not aware of why you favor this
> behavior?
>

To me, overriding methods that define a wrong return type should remove
their return type as a fix, and replace it with the attribute. Removing a
return type is allowed by LSP, so this should be just fine.

Nicolas

--00000000000056dd5a05bf64e197--