Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112625
MIME-Version: 1.0
Date: Mon, 28 Dec 2020 19:54:09 +0100
Message-ID: <CAH5C8xUhozPLq=q6RE0D7pF-qB-2D+pCwyazGRmyzJ1KRVU2cw@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003b818b05b78acd49"
Subject: [RFC] Adding return types to internal methods (PHP 8)
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--0000000000003b818b05b78acd49
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Internals,

Last year, Nikita started a discussion about adding return types
to non-final internal methods: https://externals.io/message/106539 .

I'd like to restart the conversation, since I've just created an
implementation
for the first step of the migration:
https://github.com/php/php-src/pull/6548
(I had to start a new email thread because I don't have the original one).

My implementation currently emits a deprecation notice during inheritance
validation
for each method which omits the return type of its parent. This means
that the parent return type is not yet enforced when the child omits it,
neither during
inheritance, nor at run-time. However, as soon as the child class declares
return types,
everything will behave as usual, so variance and run-time return value
checks
both apply. Finally, in a couple of years, PHP 9.0 could make the
declaration of
return types required.

If there are concerns about methods which are already declared with the
wrong return
type, we could lax the restrictions even further, and only emit a
deprecation notice
instead of a fatal error in this case as well.

I chose the above approach over inheriting the return type implicitly
(which was suggested
by Sara) because I believe it has a few advantages:
- It causes less BC break: methods not declaring a return type will surely
continue to work
as before, and gradual migration it also supported
- It has negligible run-time impact because diagnostics is emitted maximum
once per
any method which misses the return type. If return types were inherited
implicitly,
incorrect return values would potentially trigger lots of errors.
- It is more straightforward behavior than implicit inheritance, no "magic"
is involved

Even though I prefer the current implementation (or its more lax variant),
I'm also not
opposed to going with implicit inheritance if that's what we settle on.

I appreciate any input, especially about the possible impact of the
different approaches.

Regards:
M=C3=A1t=C3=A9

--0000000000003b818b05b78acd49--