On Thu, Apr 22, 2021 at 9:56 AM Marco Pivetta <ocram...@gmail.com> wrote:
> Hey Máté, > > On Thu, Apr 22, 2021, 09:42 Máté Kocsis <kocsismat...@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
