mvriel/Docblox — comment on commit 589ebad154ba881b6998425d81eaf677023a5b3c
File: docs/PSR.md line 514
By GaryJones:

re void:
http://manual.phpdoc.org/HTMLSmartyConverter/PHP/phpDocumentor/tutorial_tags.return.pkg.html The existing phpDocumentor implementation is for there not be a `@return void` as that doesn't count as one of the valid types.
http://en.wikipedia.org/wiki/PHPDoc#Tags (for what it's worth) also says "This tag should not be used for constructors or methods defined with a void return type."

Perhaps the void type should be allowed to stay in, optional (but effectively deprecated), to maintain backwards compatibility with existing code in the wild, with a big caveat that it SHOULD NOT be used if the `return` call is not present. The reason being, is that it doesn't actually add anything useful, and DocBlox already adds a concession in such that no explicit `return` type should appear as a `@return void`.

However, this use of `void` still goes against what the PHP site says.

```
function a() {
}
function b() {
return;
}
function c() {
return null;
}
var_dump( is_null(a()), is_null(b()), is_null(c()) ); // echos bool(true) bool(true) bool(true)
```
It's all the same type of value, so `@return null` should be the way to go. The less ambiguous route (and my preference) is to not allow `void` at all.