On Feb 14, 2015 6:28 AM, "Stanislav Malyshev" <smalys...@gmail.com> wrote: > > Hi! > > > What would be the point of *allowing* returning a value? It's clearly > > It's an error only because you declared it an error. > > > an error. We could let you return anything and then discard it, but > > now you won't spot the error in your code. > > Function return values which are going unused all the time. In PHP, > functions are very frequently called for side effects and not return > values. So returning value and discarding it is a common and perfectly > valid scenario. And it also has absolutely nothing to do with void > declaration - void declaration doesn't cause discarding the value and > you can discard the value with or without it.
I have no strong opinion on the void but reading this exact comment makes me think that there is clearly an issue here. How ignoring values is a perfectly valid scenario? Yes, there are cases where some code does not need it but it is clearly not clean nor correct. > > It's not merely for the sake of it. It makes function signatures more > > descriptive, and lets you catch bugs in your code. > > Only bug it can catch is wrongly declaring the function to be void - > which is introduced by this RFC. For me, it is a clear case of > generating error for the sake of error. No. It makes clear about what happens and what should be expected. I see it as a complement to the return type rfc. > > We already use void in the manual: why not in PHP? > > Because the manual is the *documentation*, not code. It explains that > the function does not return anything useful. It's not the same as > creating an error when function returns something useful. I did not check the implementation yet but I suppose it does not default to void, f.e. for existing codes. So I do not see about which "errors" you are talking about here. However yes, future codes (lib, apps, etc) using void will create this error and it will be pretty easy to make the caller happy, no? A common thing I see lately is to look at legacy code to consider what should or can be php tomorrow. I consider it as a strategic mistake. I am not saying we should drastically change php or force users to rely on new paradigms. But we must provide features to make php relevant for a wider audience. And it is possible to do it without making it less easy to use. We had the same discussion about OO when we developed 5.0, see where we are now. Stronger than ever. Cheers, Pierre
