Self-documenting code. I'm already using return types wherever I can, and it's nice to keep things consistent.

Also, it helps prevent the abuse of interfaces. I can say "this method does not return values" and enforce it. That can be useful on a big project, with junior devs.

I was talking more about the inconsistency between return type void when it returns null. I'm asking whether this behavior has changed and functions without a return will now return void or ???. It's a pretty big inconsistency IMHO.

Functions with a `: void` return type will still give you a NULL if you use them in an expression. I didn't want to break the property of existing PHP functions that they can always be used as expressions. I reasoned that your IDE or whatever can always warn you if you mistakenly try to use the result of such a function.

PHP's built-in functions documented as "void" also return NULL, so I suppose there's an argument from consistency.

It's a good point, and one which I personally hadn't thought about. The RFC specifically mentions it, so it's obviously a concern:

> Choosing one over the other suggests intent. If you specify a value, it suggests the value is significant. In a void function, the return value is insignificant: it's always the same and has no actual usefulness. https://wiki.php.net/rfc/void_return_type#why_isn_t_return_n...

I guess this 'pragmatism over consistency' fits in with the general ethos of PHP. I guess it's why so many people hate it, but I can't imagine a situation in which this will actually cause a problem.

Even if you have a point it wouldn't matter because making void functions return something else than null would be a big (useless) BC break.

There's a lot of code that uses "return;" to mean "return null;" and honestly I don't see it as a big problem.

The point I was trying to make is that PHP does not have -- nor should it have, I think -- a concept of void. Functions without a return statement already return null. "return;" is already equivalent to "return null;" as well, as you pointed out. It would be more consistent to type-hint return null instead of introducing a new return type (void) into the language. I know PHPDoc already uses "@return void", and I have never liked it for the same reason. It is not a concept used anywhere else in PHP, AFAIK.

I think having a void return type makes a lot of sense, because it says "this function will never return anything but null".

This is the same as other languages. In for example Java you have `public void method()`, and you then `return` which results in a `null`

Are you sure about that? I don't think you can use the results of void functions in Java as expressions.

This is completely incorrect. Java's null value is only valid as a value of an object type (e.g, Object x = null), and void functions don't return an object.

The compiler doesn't allow it, but if you call the function with for example reflection you get null.

You want to be able to communicate intent to clients of the function, especially with static tooling to check for common errors. For example:

https://github.com/facebook/hhvm/blob/HHVM-3.13/hphp/hack/te...

... has an obvious code smell detectable statically:

https://github.com/facebook/hhvm/blob/HHVM-3.13/hphp/hack/te...