> For userland, there are already ways to declare the planned return type > (aka @return in phpdoc), so we might not need any new way to declare this > from the engine pov. >
Yes, I think I agree, but I'd be curious about Nikita's opinion as well, since he brought up this problem first. > We should replace the SuppressReturnTypeNotice by the TentativeReturnType > one right away. The TentativeReturnType would mean: "I'm going to add a return type to this > method in its next major". > As a consequence, for child classes of internal methods, this would > suppress the notice. > If we get rid of the userland part of my proposal, then I think we can really rename SuppressReturnTypeNotice to TentativeReturnType. > As a corollary, adding this attribute should conflict with having a real > return type. This is the only questionable part for me, because then this RFC would cause more trouble for overriding methods which already define a wrong return type: a deprecation notice would always be triggered for them on PHP 8.1+ until return types are fixed or removed. And as we discussed it previously, fixing them is not always possible. Or is there any specific reason I'm not aware of why you favor this behavior? Máté
