-
Notifications
You must be signed in to change notification settings - Fork 7.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
never
return type for arrow functions with throw expressions
#7900
Comments
/cc: @muglug & @ondrejmirtes (authors of the RFC that introduced |
Funny - both PHPStan (https://phpstan.org/r/a18b627c-e478-4091-ab28-429523eece5e) and Psalm (https://psalm.dev/r/88e0288cfd) also report this wrong :) Unfortunately I don't have the skillset to fix this but I agree this is a PHP bug: https://3v4l.org/MOKDU |
It's not exactly wrong as long as PHP doesn't support it. |
Also true 😊 |
The general problem is that |
Would this also apply to functions returning void? https://3v4l.org/YkVBg |
PHP adds an implicit php-src/Zend/zend_language_parser.y Lines 1209 to 1215 in 266667c
We could of course not add that implicit return for
Yes, theoretically we could do the same here, although it's more controversial. E.g. // Makes sense, inner function returns `void` (`NULL`), outer function returns `void` too
fn (): void => voidFn()
// Makes sense, inner function might have desired side effects but result is not needed
fn (): void => nonVoidFn()
// Not useful, any side-effect free expression that has no purpose is discarded
fn (): void => 42 That said, this change would at least require a mail to the mailing list and likely an RFC as historically there have been quite a few disagreements with how |
The void case is definitely weird indeed. There is no way to generate a "void" value without a |
The absence of a fn (): void => voidFn();
function (): void {
return voidFn();
} It should be safe to drop the implicit fn (): void => voidFn();
function (): void {
voidFn();
} The controversial part comes from the fact that now this would also be valid code: fn (): void => 42;
function (): void {
42;
}
|
But dropping the implicit return implies that it would need to be added by users, no? Otherwise PHP would need looking at the return type in signature to decide if the statement value must be returned or not? It seems icky |
Yes, PHP could add the return depending on whether the function is Example: func returnsString() -> String {
return "Foo"
}
let closure1 = { () -> String in returnsString() }
print(closure1()) // Foo
let closure2 = { () -> () in returnsString() }
print(closure2()) // () |
This should only be necessary if the arrow function body solely contains a method/function call, doesn't it? So a literal value would always require a return statement and would (rightly so) cause a fatal error given a different return type. |
Other expressions can also have side effects. E.g. fn (): void => match ($foo) {
'foo' => bar(),
} I wouldn't complicate the matter even more and just do everything or nothing. |
Fixes phpGH-7900 Closees phpGH-9103
Description
The following code:
Resulted in this output:
But I expected this output instead:
Obviously, it's caused by implicit return, but throw expressions never actually return.
PHP Version
8.1.x
Operating System
No response
The text was updated successfully, but these errors were encountered: