Re: [RFC] Void Return Type (v0.2, reöpeni ng)

On Wed, Oct 14, 2015 at 3:47 PM Levi Morrison <levim@php.net> wrote: > On Wed, Oct 14, 2015 at 4:00 PM, Stanislav Malyshev <smalyshev@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 > >