Am 10.05.20 um 18:26 schrieb John Bafford:

Hi Ralph,

Hi!

Intro

I am proposing what is a near completely syntactical addition (only change is to language.y) to the language. The best terminology for this syntax is are: return if, "return early", or "guard clauses".

see: https://en.wikipedia.org/wiki/Guard_(computer_science)

Over the past few years, I've seen a growing number of blog posts, conference talks, and even tooling (for example code complexity scoring), that suggest writing guard clauses is a good practice to utilize. I've also seen it more prevalent in code, and even attempts at achieving this with Exceptions (in an HTTP context) in a framework like Laravel.

see abort_if/throw_if: https://laravel.com/docs/7.x/helpers#method-abort-if

It is also worth mentioning that Ruby has similar features, and I believe they are heavily utilized:

see: https://github.com/rubocop-hq/ruby-style-guide#no-nested-conditionals

Proposal

In an effort to make it a first class feature of the language, and to make the control flow / guard clauses more visible when scanning code, I am proposing this in the syntax of adding return if.

The chosen syntax is:

return if ( if_expr ) [: optional_return_expression] ;

As a contrived example:

function divide($dividend, $divisor = null) {
    return if ($divisor === null || $divisor === 0);

    return $dividend / $divisor;
}

There is already a little discussion around the choice of order in the above statement, the main take-aways and (my) perceived benefits are:

• it keeps the intent nearest the left rail of the code (in normal/common-ish coding standards)

• it treats "return if" as a meta-keyword; if must follow return for the statement to be a guard clause. This also allows a person to more easily discern "returns" from "return ifs" more easily since there is not an arbitrary amount of code between them (for example if the return expression were after return but before if).

• it has the quality that optional parts are towards the end

• is also has the quality that the : return_expression; is very symmetrical to the way we demarcate the return type in method signatures
  "): return type {" for example.

• has the quality of promoting single-line conditional returns

Finally

One might say this is unnecessary syntactic sugar, which is definitely arguable. But we do have multiple ways of achieving this.

Of course all of these things should be discussed, I think sub-votes (should this PR make it that far) could be considered.

The PR is located here:

https://github.com/php/php-src/pull/5552

As mentioned, some discussion is happening there as well.

Thanks!
Ralph Schindler

PS: since implementing the ::class feature 8 years ago, the addition of the AST abstraction made this kind of syntactical change proof-of-concept so much easier, bravo!
I'm in favor of language features that encourage defensive coding, so, I think the concept behind return-if is good, but your approach too limited.

I think a more general guard syntax would be better:

guard (some condition) else {
//code here must exit the parent block, or else an error is generated (at compile-time if possible)
}

This would allow for more and broader use cases: the code in the else clause could do any of return, continue, break, throw, exit, or maybe even goto, as appropriate to the condition and its parent block, which could be any functional block — a function, loop, if, else, try, or catch clause, or the "global" scope outside of a function or class definition. And, if you did return (as opposed to something else), you'd retain locality of 'return' and the return value, rather than separating it with the condition.

-John

Hi all,

In contrast, I really like Ralph's proposal for it's simplicity. I would
prefer a single keyword, though.

Hello,

I think that we SHOULD not introduce a new keyword (e. g. guard) since that
would be a "major major" backwards incompatibility. "Guard" is a really
generic
word and a great example of that is Laravel and their authentication guards.

In general, I don't think that early returns require a seperate syntax
and/or
block statement since a simple if (...) { return; } is already sufficient
enough.

Best regards,
Benas Seliuginas

Suggestion:

return if $x > 1; (to return "void")
return $y if ($x > 1 && $x < 5);
break if $x > 1;
break 2 if $x > 1;
throw new Exception if $x > 1;

Em dom, 10 de mai de 2020 15:48, Nikita Popov nikita.ppv@gmail.com
escreveu:

On Sun, May 10, 2020 at 5:49 PM Ralph Schindler ralph@ralphschindler.com
wrote:

Hi!

Intro

I am proposing what is a near completely syntactical addition (only
change is to language.y) to the language. The best terminology for this
syntax is are: return if, "return early", or "guard clauses".

see: https://en.wikipedia.org/wiki/Guard_(computer_science)

Over the past few years, I've seen a growing number of blog posts,
conference talks, and even tooling (for example code complexity
scoring), that suggest writing guard clauses is a good practice to
utilize. I've also seen it more prevalent in code, and even attempts at
achieving this with Exceptions (in an HTTP context) in a framework like
Laravel.

see abort_if/throw_if:
https://laravel.com/docs/7.x/helpers#method-abort-if

It is also worth mentioning that Ruby has similar features, and I
believe they are heavily utilized:

see:
https://github.com/rubocop-hq/ruby-style-guide#no-nested-conditionals

Proposal

In an effort to make it a first class feature of the language, and to
make the control flow / guard clauses more visible when scanning code, I
am proposing this in the syntax of adding return if.

The chosen syntax is:

return if ( if_expr ) [: optional_return_expression] ;

As a contrived example:

 function divide($dividend, $divisor = null) {
     return if ($divisor === null || $divisor === 0);

     return $dividend / $divisor;
 }

There is already a little discussion around the choice of order in the
above statement, the main take-aways and (my) perceived benefits are:

• it keeps the intent nearest the left rail of the code (in
  normal/common-ish coding standards)

• it treats "return if" as a meta-keyword; if must follow return for
  the statement to be a guard clause. This also allows a person to more
  easily discern "returns" from "return ifs" more easily since there is
  not an arbitrary amount of code between them (for example if the return
  expression were after return but before if).

• it has the quality that optional parts are towards the end

• is also has the quality that the : return_expression; is very
  symmetrical to the way we demarcate the return type in method signatures
  "): return type {" for example.

• has the quality of promoting single-line conditional returns

Finally

One might say this is unnecessary syntactic sugar, which is definitely
arguable. But we do have multiple ways of achieving this.

Of course all of these things should be discussed, I think sub-votes
(should this PR make it that far) could be considered.

The PR is located here:

https://github.com/php/php-src/pull/5552

As mentioned, some discussion is happening there as well.

Thanks!
Ralph Schindler

PS: since implementing the ::class feature 8 years ago, the addition of
the AST abstraction made this kind of syntactical change
proof-of-concept so much easier, bravo!

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.

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...

Regards,
Nikita

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.

Thanks!
Ralph Schindler

A few thoughts:

1. I agree with the sentiment that this syntactic sugar doesn't
   actually save any verbosity, so it's not really syntactic sugar at
   all.

2. There appears to now be another RFC by Pavel Patapau, specifically
   focused on a Guard statement as a new keyword
   (https://wiki.php.net/rfc/guard_statement), which now has its separate
   discussion.

3. As Thomas Lamy mentioned, I too would prefer a single keyword.
   Consider the following two examples:

   function foo($bar)
   {
   if ($bar === 1)
   return;

    if ($bar === 666)
        delete_everything();
   

   }

   function foo($bar)
   {
   if ($bar === 1)
   return

    if ($bar === 666);
        delete_everything();
   

   }

Both would now be valid syntax, and IDEs would have a harder time
warning about the misplaced semicolon in the second example. Wouldn't
be very common, but still.

4. However, this RFC is interesting to me because there be a way to
   modify it to allow for less verbose refactoring, and kinda allowing
   returns to bubble up like exceptions do. I think it would only make
   sense if it's a "if not null then return" type of thing.

Consider the following (a bit contrived, but I hope you get the point):

function main_function()
{
    $result = calculate($var);
    if ($result !== null)
        return $result;

    /* do other important stuff */
}

function main_function()
{
    ifnotnullreturn calculate($var);

    /* do other important stuff */
}

Obviously not an ideal keyword, but this is the only thing I can think
of where this type of syntactic sugar makes sense and decreases
verbosity. Something similar can also be accomplished with exception
though.

5. Finally, I think if we start putting several returns at the same
   indentation then the cognitive load increases because we can no longer
   tell if a return is actually a return at a glance.

Thanks,
Peter

Hi internals,

I think it's just as good to write:
if ($condition) return $retval;
Yes, there are subtle semantic differences the new syntax would emphasize, but it doesn't feel like it justifies it. New syntax also means the need to support it, for IDEs and other tools, static analysis tools, code-style tools - and all that for a very tiny benefit, if any.
Cheers,
Victor

Sent from Mailspring (85C8412B-B04A-4853-8C4C-E270FCB35EEE@getmailspring.com/0?redirect=https%3A%2F%2Fgetmailspring.com%2F&recipient=aW50ZXJuYWxzQGxpc3RzLnBocC5uZXQ%3D" rel="nofollow" target="_blank">https://link.getmailspring.com/link/85C8412B-B04A-4853-8C4C-E270FCB35EEE@getmailspring.com/0?redirect=https%3A%2F%2Fgetmailspring.com%2F&recipient=aW50ZXJuYWxzQGxpc3RzLnBocC5uZXQ%3D), the best free email app for work

Hi! # Intro I am proposing what is a near completely syntactical addition (only change is to language.y) to the language. The best terminology for this syntax is are: return if, "return early", or "guard clauses". see: https://en.wikipedia.org/wiki/Guard_(computer_science) Over the past few years, I've seen a growing number of blog posts, conference talks, and even tooling (for example code complexity scoring), that suggest writing guard clauses is a good practice to utilize. I've also seen it more prevalent in code, and even attempts at achieving this with Exceptions (in an HTTP context) in a framework like Laravel. see abort_if/throw_if: https://laravel.com/docs/7.x/helpers#method-abort-if It is also worth mentioning that Ruby has similar features, and I believe they are heavily utilized: see: https://github.com/rubocop-hq/ruby-style-guide#no-nested-conditionals # Proposal In an effort to make it a first class feature of the language, and to make the control flow / guard clause
s more visible when scanning code, I am proposing this in the syntax of adding return if. The chosen syntax is: return if ( if_expr ) [: optional_return_expression] ; As a contrived example: function divide($dividend, $divisor = null) { return if ($divisor === null || $divisor === 0); return $dividend / $divisor; } There is already a little discussion around the choice of order in the above statement, the main take-aways and (my) perceived benefits are: - it keeps the intent nearest the left rail of the code (in normal/common-ish coding standards) - it treats "return if" as a meta-keyword; if must follow return for the statement to be a guard clause. This also allows a person to more easily discern "returns" from "return ifs" more easily since there is not an arbitrary amount of code between them (for example if the return expression were after return but before if). - it has the quality that optional parts are towards the end - is also has the quality that the : return_expression;
is very symmetrical to the way we demarcate the return type in method signatures "): return type {" for example. - has the quality of promoting single-line conditional returns # Finally One might say this is unnecessary syntactic sugar, which is definitely arguable. But we do have multiple ways of achieving this. Of course all of these things should be discussed, I think sub-votes (should this PR make it that far) could be considered. The PR is located here: https://github.com/php/php-src/pull/5552 As mentioned, some discussion is happening there as well. Thanks! Ralph Schindler PS: since implementing the ::class feature 8 years ago, the addition of the AST abstraction made this kind of syntactical change proof-of-concept so much easier, bravo!