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

From: Date: Thu, 15 Oct 2015 15:32:07 +0000
Subject: Re: [RFC] Void Return Type (v0.2, reöp ening)
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-88815@lists.php.net to get a copy of this message
Hey Chris, Chris Riley wrote:
Semantically, I don't believe that there is sufficient difference between "returns no value" and "returns a value which has been defined as having no value" for us to care about it. The main difference you get between return type of null and a return type of void seems to be some extra fatal errors, for a developer there seems little value. From a user confusion point of view; PHP currently considers return; and return null; to be equivalent (in fact some code style checkers will replace one with the other) If (and only if) a function has a return type of void these two statements are no longer equivalent - one is a fatal error one is not. For any other return type specification, return null; and return; would behave the same. This in itself would be enough for me to be against adding a return type of void.
This is true, but void isn't an ordinary return type. It exists to ensure a function doesn't return anything, unlike other return types which exist to ensure a function returns a specific thing. return null; is *technically* equivalent to return;, but it's not quite the same in intent, usually. We could special-case it and allow it, but why? The return value isn't supposed to be used, why should we allow you to specify it? A void function in PHP does technically produce a result of null, but it might as well be false or -1 or whatever for all we care. Also, if return null; is to work, should return(null); also work? How about return \null;? return SOME_NULL_CONSTANT;? It seems silly to me since, again, the return value is insigificant. Thanks. -- Andrea Faulds http://ajf.me/

« previous php.internals (#88815) next »