Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114100
MIME-Version: 1.0
References: <CAH5C8xX87sVh5NDuQ1EfeEbSxdHawO5yNfk5zHEToAqYGJa7=Q@mail.gmail.com>
 <CADyq6sJ5StVLhgEW86xXcVeETTBUodXWrFkv0Lpin+9+du_WJg@mail.gmail.com>
 <CAF+90c8BJ5Fm05ON8_1WU6oWrgXKk49ynfO+axLJU8MqLhY_-Q@mail.gmail.com>
 <CADyq6sJ+0jiGca64wyVqHGxJOxmnCnKc8W5CTmoyFJMAS6kQnA@mail.gmail.com> <CAH5C8xWEmzcbmawgtdMN+PC1mjFx0PS9+AQepztuThQwqEDm2Q@mail.gmail.com>
In-Reply-To: <CAH5C8xWEmzcbmawgtdMN+PC1mjFx0PS9+AQepztuThQwqEDm2Q@mail.gmail.com>
Date: Thu, 22 Apr 2021 12:37:09 +0200
Message-ID: <CADyq6sJwx0ojERj7QMy_j542YNEO7T=SrseGg7pH0pw=4Z_Bvg@mail.gmail.com>
To: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a3f72305c08d4304"
Subject: Re: [PHP-DEV] [RFC] [Vote] Adding return types to internal methods
From: ocramius@gmail.com (Marco Pivetta)

--000000000000a3f72305c08d4304
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey M=C3=A1t=C3=A9, NikiC,

On Thu, Apr 22, 2021 at 12:15 PM M=C3=A1t=C3=A9 Kocsis <kocsismate90@gmail.=
com> wrote:

> Overall, I see the change of reported `ReflectionMethod#getReturnType()`
>> as non-problematic, and tooling around reflection would continue working=
 as
>> expected, while adding new API requires:
>>
>
> I do think it would be problematic, and a new API is a must (either the
> one Nikita asked about or the current one). Let's consider a
> reflection-based static analyser: in PHP 8.1, it would report the
> incompatible
> user-land return types as a very serious issue all of a sudden, while in
> fact it's not the case yet.
>
> (now I see that Nikita answered the same)
>
> M=C3=A1t=C3=A9
>

No, that's not serious: type-checkers operate pre-runtime, so it is good
that they proactively report a variance issue when a subtype of an
interface is not restrictive on a return types.

Compared to the effort to be added to support the new behavior **at
runtime**, this is a non-problem.

Current static analyzers already report issues like these, and already rely
on `ReflectionMethod#isInternal()` to determine if they should care or not
about a missing type declaration (hence no need for a new API).

Examples:

 * https://phpstan.org/r/530583f0-fab5-4f46-af6b-332e67b862cf
 * https://psalm.dev/r/7f987b25a3

In fact, a lot of tooling treats `Reflection*#isInternal()` as a huge red
flag that means "here be dragons", which is more than sufficient to move
ahead :-)

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--000000000000a3f72305c08d4304--