> 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. >
This would mean that the RFC could describe how userland (code analyzers) should understand the TentativeReturnType when encountering one, without asking anything from the engine when base userland classes are extended. For internal classes, the attribute would just mean what you wrote already. That'd be fine to me. > 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? > To me, overriding methods that define a wrong return type should remove their return type as a fix, and replace it with the attribute. Removing a return type is allowed by LSP, so this should be just fine. Nicolas
