Hi everyone,
I’ve written a small RFC and patch to add a “void” return type:
https://wiki.php.net/rfc/void_return_type
Please have a read over it. I think this would be a simple, yet useful addition.
Thanks!
Andrea Faulds
http://ajf.me/
Do we really have to throw an catchable fatal error?
the other return types make sense, why so strict?
Hi everyone,
I've written a small RFC and patch to add a "void" return type:
https://wiki.php.net/rfc/void_return_type
Please have a read over it. I think this would be a simple, yet useful
addition.Thanks!
Andrea Faulds
http://ajf.me/--
--
Reeze Xia
http://reeze.cn
Hi,
Do we really have to throw an catchable fatal error?
the other return types make sense, why so strict?
We throw E_RECOVERABLE_ERROR for all type errors, both for parameters and return types. It's not anything new.
--
Andrea Faulds
http://ajf.me/
De : Andrea Faulds [mailto:ajf@ajf.me]
I’ve written a small RFC and patch to add a “void” return type:https://wiki.php.net/rfc/void_return_type
Please have a read over it. I think this would be a simple, yet useful addition.
That's a nice addition and a beginning to distinguish void from null, as I imagine the function still returns null.
Now, what about making void a real zval type ? It would open a lot of possibilities. Unlike null, conversions from void would raise an error. It would also be rejected as argument input type but could be used as an output type when arg is passed by ref, it could be the default type for return_value (huge BC break here) and so on...
There's a need for a real 'no value' type different from null, as null has too many uses. If defined correctly, it can be a powerful addition.
François
HI,
De : Andrea Faulds [mailto:ajf@ajf.me]
I've written a small RFC and patch to add a "void" return type:https://wiki.php.net/rfc/void_return_type
Please have a read over it. I think this would be a simple, yet useful
addition.That's a nice addition and a beginning to distinguish void from null, as I
imagine the function still returns null.Now, what about making void a real zval type ? It would open a lot of
possibilities. Unlike null, conversions from void would raise an error. It
would also be rejected as argument input type but could be used as an
output type when arg is
passed by ref, it could be the default type for return_value (huge BC break
here) and so on...
There's a need for a real 'no value' type different from null, as null has
too many uses. If defined correctly, it can be a powerful addition.
What is the benefit of passing a void value around just for return type?
and the rest of engine will have to take care of IS_VOID type,
it seems doesn't worth it.
François
--
--
Reeze Xia
http://reeze.cn
Hey François,
That's a nice addition and a beginning to distinguish void from null, as I imagine the function still returns null.
Now, what about making void a real zval type ? It would open a lot of possibilities. Unlike null, conversions from void would raise an error. It would also be rejected as argument input type but could be used as an output type when arg is passed by ref, it could be the default type for return_value (huge BC break here) and so on...
We could do this, but for the longest time we've made all functions have some return value, even ones which don't explicitly return one (they return NULL). I think it'd be better not to change this. I expect IDEs and such could earn you about it, though.
There's a need for a real 'no value' type different from null, as null has too many uses. If defined correctly, it can be a powerful addition.
If I was to go back to 1994, I'd add "undefined" to PHP like JS has. Today, though, I think that is unrealistic, as much as I wish it wasn't. A void type only really makes sense as a pseudo-type for return type checking purposes, IMO.
Thanks.
We could do this, but for the longest time we've made all functions have some return value, even ones which don't explicitly return one (they return NULL). I think it'd be better not to change this. I expect IDEs and such could earn you about it, though.
All existing functions have a return value. That would not change.
If someone makes one of their functions void then where they use it could not be
where a value is needed. So: expect it in new code; but in 5 years time that
code will be mature.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h
Hey:
Hi everyone,
I’ve written a small RFC and patch to add a “void” return type:
https://wiki.php.net/rfc/void_return_type
Please have a read over it. I think this would be a simple, yet useful addition.
be honest, I think it's only part of the idea is implemented.
which make it useless.
in PHP, even if you don't return anything, NULL is returned implicitly.
even if a function is declared return nothing(void).
like:
function a() : void {};
following codes still works:
$b = a();
so, if you want a void return type, and if you want it to be a useful feature..
above expr should be invalid with an error " a() return nothing"
so, I am -1 on this in complete RFC
thanks
Thanks!
Andrea Faulds
http://ajf.me/--
--
Xinchen Hui
@Laruence
http://www.laruence.com/
function a() : void {};
following codes still works:
$b = a();
so, if you want a void return type, and if you want it to be a useful feature..
above expr should be invalid with an error " a() return nothing"
+1 - my first thought.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h
Hi,
Hey:
be honest, I think it's only part of the idea is implemented.which make it useless.
in PHP, even if you don't return anything,
NULLis returned implicitly.even if a function is declared return nothing(void).
like:
function a() : void {};
following codes still works:
$b = a();
so, if you want a void return type, and if you want it to be a useful feature..
above expr should be invalid with an error " a() return nothing"
I'm not sure about this. PHP has always made functions valid rvalues, for better or for worse. This RFC could make void functions "truly" void, but that would be a massive change to support value-less function returns. It would also break existing code which assumes all functions return a value, which isn't good.
I think this RFC is enough: it would let you enforce that a function doesn't return anything and makes code more self-documenting. It doesn't affect anything trying to use the function's implicit return value of NULL, but IDEs and code linters would surely pick up on it for you. It's still useful even if it doesn't bind the caller.
Thanks.
Hi,
De : Andrea Faulds [mailto:ajf@ajf.me]
following codes still works:
$b = a();
so, if you want a void return type, and if you want it to be a useful
feature..above expr should be invalid with an error " a() return nothing"
I'm not sure about this. PHP has always made functions valid rvalues, for
better or for worse. This RFC could make void functions "truly" void
What about renaming this hint to 'null', instead of 'void'. I know that it
supports no explicit return and 'return;' with no value but what it does is
more checking that return value is null, than checking return value is
'void', whose concept is not defined yet.
It would remove the ambiguity on the fact that the return value is used or
not. The only justification is that, in PHP, not returning an explicit
value, or using 'return;' returns null, that's history, period.
I think it would make the concept easier to understand and would reserve the
ambiguous 'void' keyword for the future, if it finds a utility one day.
Cheers
François
Sorry, I forgot that replacing 'void' with 'null' should support 'return
null;' of course. If we don't really enforce 'void', distinguishing this
from 'return;' is inconsistent, IMO.
-----Message d'origine-----
De : François Laupretre [mailto:francois@php.net]
Envoyé : dimanche 15 février 2015 11:29
À : 'Andrea Faulds'; 'Xinchen Hui'
Cc : 'PHP Internals'
Objet : RE: [PHP-DEV] [RFC] Void Return TypeHi,
De : Andrea Faulds [mailto:ajf@ajf.me]
following codes still works:
$b = a();
so, if you want a void return type, and if you want it to be a useful
feature..above expr should be invalid with an error " a() return nothing"
I'm not sure about this. PHP has always made functions valid rvalues,
for
better or for worse. This RFC could make void functions "truly" voidWhat about renaming this hint to 'null', instead of 'void'. I know that it
supports no explicit return and 'return;' with no value but what it does
is
more checking that return value is null, than checking return value is
'void',
whose concept is not defined yet.It would remove the ambiguity on the fact that the return value is used or
not. The only justification is that, in PHP, not returning an explicit
value, or
using 'return;' returns null, that's history, period.I think it would make the concept easier to understand and would reserve
the ambiguous 'void' keyword for the future, if it finds a utility one
day.Cheers
François
Hey:
Hi everyone,
I’ve written a small RFC and patch to add a “void” return type:
https://wiki.php.net/rfc/void_return_type
Please have a read over it. I think this would be a simple, yet useful
addition.
be honest, I think it's only part of the idea is implemented.which make it useless.
in PHP, even if you don't return anything,
NULLis returned implicitly.even if a function is declared return nothing(void).
like:
function a() : void {};
following codes still works:
$b = a();
so, if you want a void return type, and if you want it to be a useful
feature..above expr should be invalid with an error " a() return nothing"
so, I am -1 on this in complete RFC
Hi Xinchen!
While doing something like $b = a() where a() is a void function does not
make sense usually (and e.g. C will generate a warning/error for this) in
PHP there are some cases where you would want to use the return value of a
void function. Namely those are cases where you aren't calling a specific
function, but a callback that can return anything instead. E.g. consider
something like a partial application helper:
function bind($fn, ...$bindArgs) {
return function(...$args) use($fn) {
return $fn(...$bindArgs, ...$args);
};
}
Right now this would work no matter how $fn is declared. However if you
disallow using the return value of void functions, you'd have to create an
extra bindVoid() function which does exactly the same thing, just without
the "return".
As such I don't think we can reasonably forbid using the return value of a
void function. The utility of the "void" return type in PHP would be
self-documenting function signatures. An IDE (or other static analyzer)
would of course detect cases where the return value of a void function is
used.
Nikita
Hi!
I’ve written a small RFC and patch to add a “void” return type:
https://wiki.php.net/rfc/void_return_type
Please have a read over it. I think this would be a simple, yet useful addition.
I'm not sure what it is useful for, exactly. I mean, the more fatal
errors the merrier, but I fail to see what exactly use except having yet
more cases when your code may break it provides. I mean, if you defined
a void function, that means you're not using it return value anywhere.
Then who cares what return statement says? If you are using its return
value, then a) why you declared it as void and b) how comes you expect
return value from a function that is supposed to always return null?
Additionally, this RFC gets inheritance wrong - having return from
function that previously did not return anything is not a violation of
contract, since there's no practical contract that can rely on function
not returning anything (in fact, there's no way in PHP to even check
that AFAIK).
Summarily, this seems to me an exercise in strictness for the sake of
strictness. There are languages that force people to abide by a lot of
rules because their creators believe more rules is the same as better
code, but PHP never was one of them and the fact there are so many
people trying to make PHP that makes me sad.
Stas Malyshev
smalyshev@gmail.com
Hi,
Hi!
I'm not sure what it is useful for, exactly. I mean, the more fatal
errors the merrier, but I fail to see what exactly use except having yet
more cases when your code may break it provides. I mean, if you defined
a void function, that means you're not using it return value anywhere.
Then who cares what return statement says?
What would be the point of allowing returning a value? It's clearly an error. We could let you return anything and then discard it, but now you won't spot the error in your code.
Additionally, this RFC gets inheritance wrong - having return from
function that previously did not return anything is not a violation of
contract, since there's no practical contract that can rely on function
not returning anything (in fact, there's no way in PHP to even check
that AFAIK).
I am wondering about inheritance as well. I thought of void as having no subclass. But it's not really a return type for our purposes, it's more like a declaration that a function doesn't return anything.
So, I guess inheritance should allow removing or changing the typehint if it is void. I might need more opinions on this first, though.
Summarily, this seems to me an exercise in strictness for the sake of
strictness. There are languages that force people to abide by a lot of
rules because their creators believe more rules is the same as better
code, but PHP never was one of them and the fact there are so many
people trying to make PHP that makes me sad.
It's not merely for the sake of it. It makes function signatures more descriptive, and lets you catch bugs in your code.
We already use void in the manual: why not in PHP?
--
Andrea Faulds
http://ajf.me/
Hi!
What would be the point of allowing returning a value? It's clearly
It's an error only because you declared it an error.
an error. We could let you return anything and then discard it, but
now you won't spot the error in your code.
Function return values which are going unused all the time. In PHP,
functions are very frequently called for side effects and not return
values. So returning value and discarding it is a common and perfectly
valid scenario. And it also has absolutely nothing to do with void
declaration - void declaration doesn't cause discarding the value and
you can discard the value with or without it.
It's not merely for the sake of it. It makes function signatures more
descriptive, and lets you catch bugs in your code.
Only bug it can catch is wrongly declaring the function to be void -
which is introduced by this RFC. For me, it is a clear case of
generating error for the sake of error.
We already use void in the manual: why not in PHP?
Because the manual is the documentation, not code. It explains that
the function does not return anything useful. It's not the same as
creating an error when function returns something useful.
Stas Malyshev
smalyshev@gmail.com
On Sat, Feb 14, 2015 at 3:28 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
What would be the point of allowing returning a value? It's clearly
It's an error only because you declared it an error.
an error. We could let you return anything and then discard it, but
now you won't spot the error in your code.Function return values which are going unused all the time. In PHP,
functions are very frequently called for side effects and not return
values. So returning value and discarding it is a common and perfectly
valid scenario. And it also has absolutely nothing to do with void
declaration - void declaration doesn't cause discarding the value and
you can discard the value with or without it.It's not merely for the sake of it. It makes function signatures more
descriptive, and lets you catch bugs in your code.Only bug it can catch is wrongly declaring the function to be void -
which is introduced by this RFC. For me, it is a clear case of
generating error for the sake of error.We already use void in the manual: why not in PHP?
Because the manual is the documentation, not code. It explains that
the function does not return anything useful. It's not the same as
creating an error when function returns something useful.
One of the primary purposes of having typehints is documentation. This
applies both to our existing type annotations, to the newly introduced
return declarations - and to the void return type. The advantage of having
the type declaration be part of the language (rather than a docblock) is
brevity on one hand and verification of its correctness on the other hand.
It's easy to forget to update docblock type annotations, but you can't get
away with specifying an incorrect language-supported annotations - if you
use a wrong type annotation your code just won't work.
The void return type is actually the one case where we can at compile-time
fully verify that it is used correctly - which is great.
Allowing to return a value from a void function doesn't make sense. If you
want to return a value, don't declare it as void. If you declare it as
void, don't return a value. It's really as simple as that.
Nikita
Hi!
One of the primary purposes of having typehints is documentation. This
Documentation causing fatal errors is something quite unusual. And wrong.
applies both to our existing type annotations, to the newly introduced
That is not true, for existing types documentation is not the only and
not the primary purpose. Primary purpose is ensuring the method gets the
value it expects. Otherwise phpdoc would be enough.
return declarations - and to the void return type. The advantage of
having the type declaration be part of the language (rather than a
docblock) is brevity on one hand and verification of its correctness on
the other hand. It's easy to forget to update docblock type annotations
There's absolutely no brevity advantage and verification, as I
mentioned, in this case is not very useful.
The void return type is actually the one case where we can at
compile-time fully verify that it is used correctly - which is great.
No, you can not, since you have no idea how your function is used and
where.
Allowing to return a value from a void function doesn't make sense. If
Having language-enforced concept of "void function" in PHP doesn't make
sense. PHP functions always return values, and verifying that function
pretends to not return value has no use, as no code can depend on it.
you want to return a value, don't declare it as void. If you declare it
as void, don't return a value. It's really as simple as that.
That's exactly kind of thing that makes me sad. Inviting rules in the
language that exist for their own sake and then saying "well, you don't
like it, don't break the rules!"
Stas Malyshev
smalyshev@gmail.com
Hi!
What would be the point of allowing returning a value? It's clearly
It's an error only because you declared it an error.
an error. We could let you return anything and then discard it, but
now you won't spot the error in your code.Function return values which are going unused all the time. In PHP,
functions are very frequently called for side effects and not return
values. So returning value and discarding it is a common and perfectly
valid scenario. And it also has absolutely nothing to do with void
declaration - void declaration doesn't cause discarding the value and
you can discard the value with or without it.
I have no strong opinion on the void but reading this exact comment makes
me think that there is clearly an issue here.
How ignoring values is a perfectly valid scenario? Yes, there are cases
where some code does not need it but it is clearly not clean nor correct.
It's not merely for the sake of it. It makes function signatures more
descriptive, and lets you catch bugs in your code.Only bug it can catch is wrongly declaring the function to be void -
which is introduced by this RFC. For me, it is a clear case of
generating error for the sake of error.
No. It makes clear about what happens and what should be expected. I see it
as a complement to the return type rfc.
We already use void in the manual: why not in PHP?
Because the manual is the documentation, not code. It explains that
the function does not return anything useful. It's not the same as
creating an error when function returns something useful.
I did not check the implementation yet but I suppose it does not default to
void, f.e. for existing codes. So I do not see about which "errors" you are
talking about here.
However yes, future codes (lib, apps, etc) using void will create this
error and it will be pretty easy to make the caller happy, no?
A common thing I see lately is to look at legacy code to consider what
should or can be php tomorrow. I consider it as a strategic mistake. I am
not saying we should drastically change php or force users to rely on new
paradigms. But we must provide features to make php relevant for a wider
audience. And it is possible to do it without making it less easy to use.
We had the same discussion about OO when we developed 5.0, see where we are
now. Stronger than ever.
Cheers,
Pierre
Hi!
How ignoring values is a perfectly valid scenario?
You are saying you're using return value for every function you're
calling, always? Please. How many times you used return value of sort()?
Every function with side effects can be used for its side effects, not
for its return value.
new paradigms. But we must provide features to make php relevant for a
wider audience. And it is possible to do it without making it less easy
This sounds like cargo cult, sorry - because other languages have
"void", we have to have "void" and then their users would come to us.
That's exactly how cargo cult works - copying external appearances
without considering underlying processes. In PHP, there's no meaning to
void function except for self-enforcing documentation, and documentation
should be properly done by other means and should not produce fatal errors.
to use. We had the same discussion about OO when we developed 5.0, see
where we are now. Stronger than ever.
No, it's not like OO at all. OO is a huge conceptual framework with very
wide use and it can help with developing code and making people more
productive. Having "void" just helps with having "void".
Stas Malyshev
smalyshev@gmail.com
Hi Andrea,
Le Sat, 14 Feb 2015 04:18:28 +0100, Andrea Faulds ajf@ajf.me a écrit:
Hi everyone,
I’ve written a small RFC and patch to add a “void” return type:
https://wiki.php.net/rfc/void_return_type
Please have a read over it. I think this would be a simple, yet useful
addition.
Yup, totally useful, I use "void" a lot in other languages, it would be a
nice addition to the language. I like this RFC.
Regards,
Benoit.
Hi Andrea,
-----Ursprüngliche Nachricht-----
Von: Andrea Faulds [mailto:ajf@ajf.me]
Gesendet: Samstag, 14. Februar 2015 04:18
An: PHP Internals
Betreff: [PHP-DEV] [RFC] Void Return TypeHi everyone,
I’ve written a small RFC and patch to add a “void” return type:
https://wiki.php.net/rfc/void_return_type
Please have a read over it. I think this would be a simple, yet useful addition.
Thanks!
Andrea Faulds
http://ajf.me/--
I think a void type for PHP would make sense but only if the return value of such a function cannot be used.
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.
I suggest to use one of the following behaviours:
- declaring a function void does not return anything (hence is like echo to a certain agree)
- declaring a function void does return a thing of type void (that would be similar to Unit in scala)
- instead of void a function can be declared to be of type null -> almost the same behaviour as your RFC but without the inconsistency
Cheers,
Robert
Hi Robert,
I think a void type for PHP would make sense but only if the return value of such a function cannot be used.
Why? 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.
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.
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.
I suggest to use one of the following behaviours:
- 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.
- 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.
- 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.
--
Andrea Faulds
http://ajf.me/
-----Ursprüngliche Nachricht-----
Von: Andrea Faulds [mailto:ajf@ajf.me]
Gesendet: Samstag, 14. Februar 2015 22:38
An: Robert Stoll
Cc: PHP Internals
Betreff: Re: [PHP-DEV] [RFC] Void Return TypeHi Robert,
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)
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
NULLis 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:
- 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
- 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.
- instead of void a function can be declared to be of type null ->
almost the same behaviour as your RFC but without the inconsistencyThat 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/