Hey Máté, NikiC, On Thu, Apr 22, 2021 at 12:15 PM Máté Kocsis <kocsismat...@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áté > 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/
