On Wed, Oct 14, 2015 at 3:47 PM Levi Morrison <le...@php.net> wrote: > On Wed, Oct 14, 2015 at 4:00 PM, Stanislav Malyshev <smalys...@gmail.com> > wrote: > > Hi! > > > >> I'm reviving my Void Return Type RFC, this time for PHP 7.1: > >> > >> https://wiki.php.net/rfc/void_return_type > >> > >> Please read it and tell me your thoughts! > > > > I still see no point in this, as every PHP function actually returns > > something (at least null). So this type would not actually be right and > > would not reflect what actually is happening. > > I agree that `void` doesn't make sense given that we document that > `return;` will return null[1]. If the union types RFC[2] passes it > makes sense to allow `Foo | null` which allows something of type `Foo` > or `null`. To me it makes sense that if you then remove `Foo` you are > left with `null`, not `void`. My personal recommendation because of > this would be to use `null` for the return type and instead of `void`. >
Isn't null supposed to mean the absense of a value and not take the place of a value in PHP though? Didn't we just have a long conversation about this in a thread about PHPSadness? If I capture the result of a "void" method and check if my result variable with isset(), I'll get false. This sounds like it's void of value to me. > Also, I do not think this feature is pointless. For instance, it has > value in interfaces. Declaring that a method does not return a value > means implementors cannot accidentally return something. This is > better than just documenting that it should not be done. > This is what I was thinking too, I'm not sure that there's much value beyond that > [1]: http://php.net/manual/en/function.return.php > [2]: https://wiki.php.net/rfc/union_types > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
