Hi Nicolas,
> Oh, I didn't get this at first: you're telling that this native return > type would not be enforced when the attribute is declared? This should > answer my previous comment. > Yes, that's the case. On one hand, this solution IMO has the advantage that its syntax integrates into the ecosystem much better, including php-src itself (as I mentioned in my previous mail). On the other hand, it might be a little bit deceptive at first that the type declaration is not enforced when the attribute is present. Nonetheless, I still prefer this solution over storing types as a list of strings. I'm not sure yet this is a good idea, because it would prevent userland > libs from using this attribute in an effective way until they bump to 8.1... The main proposal is about adding return types to internal methods, and the SuppressReturnTypeNotice attribute can already be added to any libraries. But you are right in connection with the TentativeReturnType attribute, libraries would have to bump their minimum PHP version requirement to 8.1 in order to be able to add return types without a BC impact on PHP <8.1. I think it's still the less bad option. As this RFC's primary motivation is to prepare for adding return types to internal methods, I'm planning to add a secondary vote about exposing tentative return types to userland, since I'm not 100% confident that this concept is worth the special care in PHP itself. Máté
