Skip to content

feat: allow multiline arrow functions #18500

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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Conversation

xepozz
Copy link

@xepozz xepozz commented May 4, 2025

I've played with the lexer and complete the multiline arrow functions.

Implementation is quite simple:

  • old way with no {}
  • new way with {}, like the regular functions

Key points:

  • Returning from the arrow function means returning the result to the function point, not to the parent constructions
  • It should work the same way, because the old way to use arrow function used emulated RETURN ast node, which is similar to fn() => return, but it's not acceptable by the lexer. I didn't change that, just added a new way to allow multiline statements.

The last think I don't know how to solve is #7900 issue:

try {
    assert((fn(): never => {
        return 42;
    }) && false);
} catch (\Error $e) {
    echo $e->getMessage(), "\n";
}

Isn't handled by the catch, 'cause it leads to a Fatal error.
Although, it looks correct because there is no RETURN token added implicitly

@iluuu1994 I remember you've preparing long arrow functions and match expressions, but I think it can be added separately, so I can reference your RFC if I go to there. What do you think?

@iluuu1994
Copy link
Member

iluuu1994 commented May 4, 2025

Hi @xepozz. There was already an RFC for this that was declined. https://wiki.php.net/rfc/auto-capture-closure Edit: Sorry @Xepo for the wrong ping.

@xepozz
Copy link
Author

xepozz commented May 5, 2025

Heh, thanks for the answer.

That change seems very useful for me, I'll go through RFC anyway. There are no big deal between one-line and multiline functions for the php core, but the impact is significant for userland.


The another implementation looks a bit different, including Zend optimizer changes, are they necessary?

@iluuu1994
Copy link
Member

Yes. They avoid unnecessary variable capturing. I think you won't have a big chance of success submitting the RFC with no changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants