> -----Ursprüngliche Nachricht-----
> Von: Andrea Faulds [mailto:[email protected]]
> Gesendet: Samstag, 14. Februar 2015 22:38
> An: Robert Stoll
> Cc: PHP Internals
> Betreff: Re: [PHP-DEV] [RFC] Void Return Type
>
> Hi Robert,
>
> > On 14 Feb 2015, at 21:23, Robert Stoll <[email protected]> wrote:
> >
> > I think a void type for PHP would make sense but only if the return value
> > of such a function cannot be used.
>
> Why?
I already mentioned why, because it is inconsistent. I see that you look at it
from another point of view. Maybe I missed something but I figured the
following function:
function foo(){}
is equivalent to
function foo() {return;}
is equivalent to
function foo() {return null;}
or am I wrong? Does it have a different behaviour?
If not, then still claim it is inconsistent. NULL is treated as own type in PHP
(at least specs says so [1]) hence I do not see why null should be returned
when the function is defined as void (but I would also be happy with the other
suggestions below)
[1]
https://github.com/php/php-langspec/blob/0f9985ba76ab7890a9a8440f8a4344c58f0a6761/spec/05-types.md#the-null-type
> If the return value cannot be used, it prevents the function being used with
> any API that stores the return value of a callback. That’s not terribly nice.
No problem to wrap such a function into another callback returning null. It was
not defined with void for no reason, that is how I look at it.
>
> A void return value doesn’t need to enforce anything on the caller. PHP has
> always filled in missing values with NULLs,
> including return values, like other dynamic languages do here.
In what other cases does PHP fill in missing values with NULLs (expect from
return type and collection initialisation, that is something different IMO)?
>
> > Otherwise it is another reason for people to laugh at PHP and justifiably
> > so, telling that a function does not return
> anything but return null is very inconsistent.
>
> It does implicitly return NULL, but NULL is a useless value, and it’s
> returned implicitly, rather than explicitly. I don’t think it’s
> really that ludicrous.
How dare you calling NULL useless :P
Might be that other do not think it is inconsistent. For me it does not make a
difference if something is returned explicitly or implicitly, in the end it
still returns something and this something needs to be of the type the return
type hint claims to be. That is what I define consistent.
I could live with the idea of void as alias for null (or abstract parent type
of null if you do not like an alias) but otherwise, why should the following
not be allowed:
function foo : void { return null;}
when it is returned anyway if I omit the statement?
>
> > I suggest to use one of the following behaviours:
> > 1. declaring a function void does not return anything (hence is like
> > echo to a certain agree)
>
> That makes it cease to be a function in the PHP sense. PHP always allows
> functions to be used in expressions.
Sure, every function which returns something (explicitly or implicitly) can be
used in an expression. If void defines to return nothing, then it could not be
used in an expression. I do not see a problem here, no rather the other way
round. Consider the following example:
function foo() : void {}
$b = foo() + 1; //I would like to see an error here rather that 1 is assigned
to $b
>
> > 2. declaring a function void does return a thing of type void (that
> > would be similar to Unit in scala)
>
> We don’t need another form of NULL.
>
> Also, a thing of type void could be passed around, just as the unit type can
> be in other languages, so it wouldn’t do what
> you want it to.
Of course it would. void could be defined in such a way that it does not
support implicit conversions to other types. Taking the example from above the
following would result in an error as well:
function foo() : void {}
$b = foo() + 1; //would emit an error "Unsupported operand types for +" like it
is done for: new Exception() + 1;
And as someone else on the list already mentioned such an approach would allow
other features.
>
> > 3. instead of void a function can be declared to be of type null ->
> > almost the same behaviour as your RFC but without the inconsistency
>
> That seems like a strange solution. You’re requiring the function to always
> return a useless value.
Yes, that is what already happens anyway. You look at it from the wrong point
of view IMO, you did not consider the implicit return to be similar to implicit
conversions respectively. A user would not be required to write a return
statement like a user is not required to cast an int value to string when
passed to an internal function which expects string. If you think in this terms
then it makes absolutely sense to state that a function returns null.
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
> http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
