return types were incorrectly hinted as null, should be void#49
Conversation
|
It's not really though, functionally speaking, and as we have no type hints, it doesn't matter at all. I'd be +1 for merging here, seeing as PHP7.1 made void official, but to merge the change on the PSR itself I guess you'll have to go through the ML. |
|
Please send a message to the mailing list if anyone objects, as this might be considered a breaking change; if nobody does object then we can get this merged here and on the spec. If people do object then it can either go to a vote (if people care enough either way) or it needs to remain as-is here and on the spec. |
Technically, but in practice, no one has been writing So in practice, this is not a breaking change, it's a bugfix. For that matter, it's not even a bugfix, it's a documentation fix :-) |
|
Sure, it's just it's better to make sure on the ML nobody objects first. :) |
That thing is really a typehint documentation wise. It says all implementations must return null, but changing it to void means all implementations must not return. See why I'd say this is breaking? |
|
That's quite a pedantic argument though, given that |
@GrahamCampbell yes, but show me one implementation that returns? It's technically a break change, and I already said as much, but since there's not a line of code actually implementing it "correctly" according to the incorrect doc-block, changing this effectively breaks nothing. |
|
Yeh. I'm just playing devil's advocate. I do think this change is fine. I just want to make sure all points are properly considered. :) |
|
By the way, it just occurred to me - the included So this really is a bugfix. |
4 participants
Corrected all return type-hints from
nulltovoidto avoid failed inspections in e.g. Php Storm.(strict inspection would state that a function must
returnif annotated withreturn null- as opposed toreturn void, which means the function does not use a return-statement and has no defined return-value.)