Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113849
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>
In-Reply-To: <CAOWwgp=5P98umLMjof5QM6CbKqr8+nE7nvE0MCfykq+AzJizOg@mail.gmail.com>
Date: Mon, 29 Mar 2021 11:19:26 +0200
Message-ID: <CAH5C8xWKz1TSGrJNDBJokds68Dqp--3oHOb4=fVOA5DA=b1BJg@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000781e5e05bea961d4"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Adding return types to internal methods
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--000000000000781e5e05bea961d4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> 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.


> 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?

M=C3=A1t=C3=A9

--000000000000781e5e05bea961d4--