Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RM approval: 👍

Thank you for sorting this out. Please make a note in NEWS (if you think it's appropriate) so we can tell people about the change in behavior.

Member Author

@Crell Please confirm whether this is the approach you want to go with.

Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Member Author

Thanks for the inputs. /cc @nikic I'm guessing PHP-Parser will want a similar patch applied.

Contributor

This makes the examples in RFC invalid. Any chance to update them?

Contributor

I have no idea what standard procedure is here. I can update the RFC if that's appropriate, but I'm not sure if that's appropriate.

Member Author

@Crell Given this was discussed publicly I think adjusting the examples is appropriate. For the sake of transparency you may add it to a change log at the top of the page, with a link to the discussion.

Member Author

I'd still change the example. It's often the only thing people look at.

Contributor

Hi, is this really necessary when the parentheses do not add any value? For example if the arrow function is the last one in the chain:

$result = $input |> $foo->doFoo(...) |> fn ($x) => $foo->doBar($x);

Adding parentheses around the arrow function is now required but does not disambiguate anything.

Member

We could work around this by scanning the AST of the fn body, to check whether it contains |>, but ... $input |> fn ($x) => ($x + 1 |> $foo->doFoo(...)); and $input |> fn ($x) => $x + 1 |> $foo->doFoo(...); for example are not distinguishable from the AST, even though the former would be fine ("last in chain").
There are such caveats which make it annoying; one simple rule "always parens-wrap it" is clearer.