Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106539
MIME-Version: 1.0
Date: Sun, 11 Aug 2019 10:43:54 +0200
Message-ID: <CAF+90c99ftVY4KndJAH_851sEAF===4iyUgSqrc3nEsL833BhQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000044633e058fd369a9"
Subject: Adding return types to internal methods (PHP 8)
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000044633e058fd369a9
Content-Type: text/plain; charset="UTF-8"

Hi internals,

Something that came up in the arginfo thread: We can now add type
annotations for everything, apart from return types on methods of non-final
classes.

The reason is that adding these return types would require inheriting
classes to specify them as well. The same problem does not exist for
argument types thanks to https://wiki.php.net/rfc/parameter-no-type-variance
(which is exactly why we wanted that RFC).

For example, if we add a "string" return type to DateTimeZone::getName(),
then any userland child of DateTimeZone would also have to specify a string
return type.

The good news: Userland classes can already specify those types *now*,
because adding a return type in a child class is legal. This means that if
we add those return types, userland extensions do not have to bump their
minimum requirement to PHP 8 when adding the return type: They can still be
compatible all the way down to PHP 7 (or 7.1, depending on the type).

What do you think about this? As we are currently annotating everything
with types, and we're at a major version, this would be the ideal time to
make this change. But there's certainly a BC break here. (And, for the
record, this is not the type of BC break where P++ or editions help,
without creating a larger mess.)

Regards,
Nikita

--00000000000044633e058fd369a9--