Hi internals,
In the nullable types we do not allow implicit return null/return with no
value to fulfill a nullable type.
- No return will result in a TypeError when executed
- Return with no value will be an actual fatal error, which I believe is
due to the fact it's not found at runtime, should be a TypeError or
ParseError if possible? - Return explicit null is fine (as expected)
I believe the first two are contrary to PHP's "null is always returned if
nothing else is".
OTOH, it makes sense as it's the entire reasoning behind return void vs
return null.
This behavior is completely undocumented in the RFC.
It's definitely something we should make an explicit decision on for the
language spec if nothing else.
We should also make any decisions on this prior to beta3 in < 2 weeks.
Thoughts?
- Davey
Hi internals,
In the nullable types we do not allow implicit return null/return with no
value to fulfill a nullable type.
- No return will result in a TypeError when executed
- Return with no value will be an actual fatal error, which I believe is
due to the fact it's not found at runtime, should be a TypeError or
ParseError if possible?- Return explicit null is fine (as expected)
I believe the first two are contrary to PHP's "null is always returned if
nothing else is".OTOH, it makes sense as it's the entire reasoning behind return void vs
return null.This behavior is completely undocumented in the RFC.
It's definitely something we should make an explicit decision on for the
language spec if nothing else.We should also make any decisions on this prior to beta3 in < 2 weeks.
Thoughts?
- Davey
hello_2 looks particularly fishy to me; to my knowledge we did not pass any
RFCs that would dictate such a message. However I have not been as active
as I'd like to be so perhaps I just missed it.
Hi internals,
In the nullable types we do not allow implicit return null/return with no
value to fulfill a nullable type.
- No return will result in a TypeError when executed
- Return with no value will be an actual fatal error, which I believe is
due to the fact it's not found at runtime, should be a TypeError or
ParseError if possible?
It's a compile time error. Compile time errors are currently fatal errors
for technical reasons.
- Return explicit null is fine (as expected)
I believe the first two are contrary to PHP's "null is always returned if
nothing else is".OTOH, it makes sense as it's the entire reasoning behind return void vs
return null.
Indeed. The current behavior is consistent with the (explicit decision
from) the void RFC.
Additionally, the current behavior is consistent with the behavior of the
implementation at the time the RFC was voted, with the only difference that
I have made this a compile-time error after the fact (because I think if we
know that something will always result in a runtime error, we should try to
detect it at compile-time already, and because the void error is detected
at compile-time as well).
Nikita
This behavior is completely undocumented in the RFC.
It's definitely something we should make an explicit decision on for the
language spec if nothing else.We should also make any decisions on this prior to beta3 in < 2 weeks.
Thoughts?
- Davey
Nikita,
Just to confirm for explicitness-sake:
Nullable return types work inversely to void return types. You must
return either the specified type, or an explicit null. Anything else is
either a TypeError (incorrect type [implicitly] returned), or a [compile
time] fatal error (return without value).
Is it worthwhile updating the RFC with this information and examples as it
is most likely what will be used to create documentation (if it's not been
documented already) and the spec.
I'm happy to do that, if that's desired.
- Davey
Hi internals,
In the nullable types we do not allow implicit return null/return with no
value to fulfill a nullable type.
- No return will result in a TypeError when executed
- Return with no value will be an actual fatal error, which I believe is
due to the fact it's not found at runtime, should be a TypeError or
ParseError if possible?It's a compile time error. Compile time errors are currently fatal errors
for technical reasons.
- Return explicit null is fine (as expected)
I believe the first two are contrary to PHP's "null is always returned if
nothing else is".OTOH, it makes sense as it's the entire reasoning behind return void vs
return null.Indeed. The current behavior is consistent with the (explicit decision
from) the void RFC.Additionally, the current behavior is consistent with the behavior of the
implementation at the time the RFC was voted, with the only difference that
I have made this a compile-time error after the fact (because I think if we
know that something will always result in a runtime error, we should try to
detect it at compile-time already, and because the void error is detected
at compile-time as well).Nikita
This behavior is completely undocumented in the RFC.
It's definitely something we should make an explicit decision on for the
language spec if nothing else.We should also make any decisions on this prior to beta3 in < 2 weeks.
Thoughts?
- Davey