Hi, > On 14 Feb 2015, at 05:54, Stanislav Malyshev <smalys...@gmail.com> wrote: > > Hi! > > I'm not sure what it is useful for, exactly. I mean, the more fatal > errors the merrier, but I fail to see what exactly use except having yet > more cases when your code may break it provides. I mean, if you defined > a void function, that means you're not using it return value anywhere. > Then who cares what return statement says?
What would be the point of *allowing* returning a value? It's clearly an error. We could let you return anything and then discard it, but now you won't spot the error in your code. > Additionally, this RFC gets inheritance wrong - having return from > function that previously did not return anything is not a violation of > contract, since there's no practical contract that can rely on function > not returning anything (in fact, there's no way in PHP to even check > that AFAIK). I am wondering about inheritance as well. I thought of void as having no subclass. But it's not really a return type for our purposes, it's more like a declaration that a function doesn't return anything. So, I guess inheritance should allow removing or changing the typehint if it is void. I might need more opinions on this first, though. > Summarily, this seems to me an exercise in strictness for the sake of > strictness. There are languages that force people to abide by a lot of > rules because their creators believe more rules is the same as better > code, but PHP never was one of them and the fact there are so many > people trying to make PHP that makes me sad. It's not merely for the sake of it. It makes function signatures more descriptive, and lets you catch bugs in your code. We already use void in the manual: why not in PHP? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
