Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114096
MIME-Version: 1.0
References: <CAH5C8xX87sVh5NDuQ1EfeEbSxdHawO5yNfk5zHEToAqYGJa7=Q@mail.gmail.com>
 <CADyq6sJ5StVLhgEW86xXcVeETTBUodXWrFkv0Lpin+9+du_WJg@mail.gmail.com>
In-Reply-To: <CADyq6sJ5StVLhgEW86xXcVeETTBUodXWrFkv0Lpin+9+du_WJg@mail.gmail.com>
Date: Thu, 22 Apr 2021 10:37:29 +0200
Message-ID: <CAF+90c8BJ5Fm05ON8_1WU6oWrgXKk49ynfO+axLJU8MqLhY_-Q@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000eb76fd05c08b9792"
Subject: Re: [PHP-DEV] [RFC] [Vote] Adding return types to internal methods
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000eb76fd05c08b9792
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 22, 2021 at 9:56 AM Marco Pivetta <ocramius@gmail.com> wrote:

> Hey M=C3=A1t=C3=A9,
>
> On Thu, Apr 22, 2021, 09:42 M=C3=A1t=C3=A9 Kocsis <kocsismate90@gmail.com=
> wrote:
>
> > Hi Internals,
> >
> > I've just opened the vote about
> > https://wiki.php.net/rfc/internal_method_return_types
> > and I will close it on 2021-05-06.
> >
> > For prior discussion, please see https://externals.io/message/113413
>
>
> Overall OK with the RFC, but we do such a.fuss about not breaking compat =
on
> inheritance for then breaking it in reflection, where we add two methods
> that completely shake down the tree.
>
> Therefore I voted NO, especially considering the implications this has on
> libraries like BetterReflection: the return type is there and it is clear=
,
> it just hasn't been explicitly declared by the engine, but there isn't a
> need for dropping it from reflection.
>
> In fact, if reflection were to switch to the actual runtime return types =
of
> those methods, I don't see a reason why downstream consumers would break
> (stubbing tools, code generators, type checkers, dependency solvers, etc.=
)
>
> I would vote yes on the RFC if this section were omitted, and reflection
> started to report the new types in 8.1 (or another 8.x).
>

It seems pretty important to me that there is a distinction between these
-- apart from one measly deprecation warning (that can be ignored), these
return types effectively do not exist. You can't treat them the same way.
If you have a (non-final) method with a tentative return type, then you
don't have a guarantee that it actually returns a value of that type.

To clarify what you're actually suggesting here: Do you want to always have
the type returned from getReturnType() and only add an additional bool
method that tells you whether that is a tentative or real type, so that
most code can just treat them as being the same thing?

Regards,
Nikita

--000000000000eb76fd05c08b9792--