> This proposal looks way too specific to me. I'm a big fan of returning
> early -- but also of throwing early, breaking early and continuing
> early. Supporting this just for returns seems odd / inconsistent to me.
I agree with this sentiment, and I'll update the PR accordingly and this
will be reflected when I make the RFC itself.
(Throw feels different as its parameter is not optional and is always a
complex type, and is in a different area of the parser... But I'll look
more deeply at adding that soon.)
> That said, I don't think this syntax solves a real problem in the first
> place. If it solves a problem, it's mostly a problem of PHP coding
> styles being a bit overzealous when it comes to formatting requirements
> for early return/break/continue/throw. And that's not a problem that
> needs solving at the language level...
I think we could say the same thing about most new additions: fn arrow
functions, str_starts_with/str_ends_with, trailing comma in lists &
function calls, str_contains(), flexible (indented) heredocs, list
reference assignment, native de-structuring.. just to name a few that
all fit into the same kind of quality of life category. Nearly all of
those were achievable via some kind of syntax before their addition, but
I think we can agree we're better off having them, than not- even if one
chooses not to use them.
Having been programming with PHP for 22+ years now, and making it a
point to evolve my tastes/preferences with the changing language and
whatever the prevalent practices are in the community (and other
languages), my desire for including these quality of life improvements
remains quite high as it keeps the language interesting and competitive.
Put another way, as someone who's come to really appreciate the
aesthetics and clarity of intent of code,.. and having seen this is some
places in the wild already I feel are successful, I personally feel its
a good thing to perhaps to run through the RFC process for inclusion in 8.