Proposal For Return-If / Early Return / Guard Clause Syntax

  110107
May 10, 2020 15:49 ralph@ralphschindler.com (Ralph Schindler)
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!
  110109
May 10, 2020 16:26 jbafford@zort.net (John Bafford)
Hi Ralph,

> On May 10, 2020, at 11:49, 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!
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
  110111
May 10, 2020 17:32 thomas.lamy@netwake.de (Thomas Lamy)
Am 10.05.20 um 18:26 schrieb John Bafford:
> Hi Ralph, > >> On May 10, 2020, at 11:49, 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! > 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.
  110114
May 10, 2020 19:19 benas.molis.iml@gmail.com (Benas IML)
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
  110117
May 10, 2020 20:00 jbafford@zort.net (John Bafford)
Benas,

> On May 10, 2020, at 15:19, Benas IML iml@gmail.com> wrote: > > 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
I think there's three main reasons for guard, as opposed to if: 1) It further and clearly establishes intent: if you see guard, you have more information about the programmer's intent and what the code will actually do. 2) It prevents having to negate the condition: guard (is valid) else, instead of if (not valid) then; negations impose additional cognitive load when attempting to understand code, especially if your condition already has a negation. 3) The language provides a guarantee that if the guard condition is not met, execution can not proceed past the else clause. This helps prevent accidental fall-through, such as if you wrote: if(!$valid) { terminate(); } expecting it to end execution (e.g. via a throw or exit), but for some reason it failed to do so. To take an idea from Ralph's original proposal, perhaps some syntax like "if guard (condition) else ...". In this context, guard could not possibly be confused with a function from the parser's point of view, instead serving as an intent modifier to if. -John
  110161
May 15, 2020 08:33 benas.molis.iml@gmail.com (Benas IML)
Hey,

`guard` would be a keyword this means that all of the classes, interfaces
and traits named Guard would be illegal. Therefore Laravel's `Guard`
interface would be incompatible with PHP 8 which in turn means thousands of
web applications would be too.

Best regards,
Benas Seliuginas
  110167
May 15, 2020 13:36 jbafford@zort.net (John Bafford)
Benas,

> On May 15, 2020, at 04:33, Benas IML iml@gmail.com> wrote: > > Hey, > > `guard` would be a keyword this means that all of the classes, interfaces and traits named Guard would be illegal. Therefore Laravel's `Guard` interface would be incompatible with PHP 8 which in turn means thousands of web applications would be too. > > Best regards, > Benas Seliuginas
If the parser were sufficiently smart, I don't think 'guard' would actually conflict with a class or function named 'guard'. If the syntax were: guard (EXPRESSION) else STATEMENT_OR_BLOCK then, 'guard' could not conflict with a class name, because there's no existing syntax that would fit the pattern of a type name followed by a parenthesis — you can't call a type name as if it were a function. Even if you could, it would still not conflict with a function call, because the 'else' keyword after the close parenthesis would not be valid syntax immediately following a function call. So the main question there is, is the parser sufficiently smart to be able to see 'guard' and look ahead for the 'else' to disambiguate a function call from a guard statement? -John
  110168
May 15, 2020 13:57 benas.molis.iml@gmail.com (Benas IML)
Hello,

Not it's not and will likely never be so using `guard` is a really bad idea.

Best regaeds,
Benas Seliuginas
  110110
May 10, 2020 16:55 carusogabriel34@gmail.com (Gabriel Caruso)
On Sun, 10 May 2020 at 17:49, 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! > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
Hello Ralph, Have you written a formal RFC document? If not, you should do it for this RFC: https://wiki.php.net/rfc/howto.
  110112
May 10, 2020 18:47 nikita.ppv@gmail.com (Nikita Popov)
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
  110113
May 10, 2020 18:56 david.proweb@gmail.com (David Rodrigues)
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 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 >
  110116
May 10, 2020 19:59 ralph@ralphschindler.com (Ralph Schindler)
On 5/10/20 1:56 PM, David Rodrigues wrote:
> 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; >
100% that will/should be a votable alternative option should this get to the voting phase. I have reasons for why I chose my initial path, but its worth mentioning I favor the optional value at the end maybe 65% to 35% where the value is after the initial keyword. Thanks for taking the time! -ralph schindler
  110119
May 10, 2020 21:33 david.proweb@gmail.com (David Rodrigues)
I just think that this way is more compatible witth the reading. "Return X
if Y" seems better than "return (if) X: (then) Y". Too the ":" could
conflicts with return type.

Em dom, 10 de mai de 2020 16:59, Ralph Schindler <ralph@ralphschindler.com>
escreveu:

> > > On 5/10/20 1:56 PM, David Rodrigues wrote: > > 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; > > > > 100% that will/should be a votable alternative option should this get to > the voting phase. > > I have reasons for why I chose my initial path, but its worth mentioning > I favor the optional value at the end maybe 65% to 35% where the value > is after the initial keyword. > > Thanks for taking the time! > -ralph schindler >
  110115
May 10, 2020 19:50 ralph@ralphschindler.com (Ralph Schindler)
> 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
  110118
May 10, 2020 20:12 rowan.collins@gmail.com (Rowan Tommins)
Hi Ralph,

Like others, I think this feels too narrow in its scope, and doesn't add 
enough over existing syntax.

You mention that Ruby has a similar feature, but there it's not a 
special syntax for guard clauses per se, but a "modifier" form of the if 
statement: 
https://docs.ruby-lang.org/en/2.7.0/syntax/control_expressions_rdoc.html#label-Modifier+if+and+unless

Along with "unless" (an alias for "if not"), it's supposed to let you 
write more sentence-like code:

print "Hat Trick!" if $goals == 3;
throw new BadInputException unless is_valid($input);

In fact, Ruby also has modifier forms of while and until; and Perl 
(where I think this all came from) also for and foreach.


I'm not sure whether I'd welcome that syntax in PHP or not, but it would 
be one way to allow the throw, break, etc cases that other people have 
mentioned in addition to return, rather than having to invent special 
syntaxes for each.

Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]
  110149
May 13, 2020 09:42 come.chilliet@fusiondirectory.org (=?UTF-8?B?Q8O0bWU=?= Chilliet)
Le Sun, 10 May 2020 10:49:15 -0500,
Ralph Schindler <ralph@ralphschindler.com> a écrit :
> 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; > }
I do not understand the point, you are just reordering keywords, why is that better than already correct code: function divide($dividend, $divisor = null) { if ($divisor === null || $divisor === 0) return; return $dividend / $divisor; } I do not think an RFC and a special keyword are justified just to move the word "return" from end to beginning of line.
  110170
May 15, 2020 18:58 crocodile2u@gmail.com (Victor Bolshov)
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 (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
On 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 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! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
  110196
May 17, 2020 04:33 sarkedev@gmail.com (Peter Stalman)
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

On Fri, May 15, 2020 at 11:58 AM Victor Bolshov <crocodile2u@gmail.com> wrote:
> > 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 (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 > On 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 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! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php >
May 19, 2020 06:53 php@manuelcanga.dev (Manuel Canga)
Hi, Internals,



 ---- En dom, 17 may 2020 06:33:51 +0200 Peter Stalman <sarkedev@gmail.com> escribió ----
 > 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
 > 

I agree. 

¿ Maybe something like...

   function main_function()
     {
         escape when(  calculate($var) );

         /* do other important stuff */
    }


`escape when( expr )`  returns value of  `expr`  to caller function  when `expr` evaluate to true otherwise next line.

   function main_function()
     {
         escape with $ a + 1  when(  !calculate($var)  );

         /* do other important stuff */
    }


`escape with expr1 when( expr2 )`  returns value of `expr1` to caller function  when `expr2` evaluate to true otherwise next line.



Regards
--
Manuel Canga
  110211
May 19, 2020 07:04 php@manuelcanga.dev (Manuel Canga)
---- En mar, 19 may 2020 08:53:46 +0200 Manuel Canga <php@manuelcanga.dev> escribió ----
 > 
 > Hi, Internals,
 > 
 > 
 > 
 >  ---- En dom, 17 may 2020 06:33:51 +0200 Peter Stalman <sarkedev@gmail.com> escribió ----
 >  > 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();
 >  >     }
 >  > 


 >  > 
 >  > 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
 >  > 
 > 
 > I agree. 
 > 
 > ¿ Maybe something like...
 > 
 >    function main_function()
 >      {
 >          escape when(  calculate($var) );
 > 
 >          /* do other important stuff */
 >     }
 > 
 > 
 > `escape when( expr )`  returns value of  `expr`  to caller function  when `expr` evaluate to true otherwise next line.
 > 
 >    function main_function()
 >      {
 >          escape with $ a + 1  when(  !calculate($var)  );
 > 
 >          /* do other important stuff */
 >     }
 > 
 > 
 > `escape with expr1 when( expr2 )`  returns value of `expr1` to caller function  when `expr2` evaluate to true otherwise next line.
 > 
 > 

Upgrade version.

Maybe is better:

`escape when( expr )`  returns null  to caller function  when `expr` evaluate to true otherwise next line.

 `escape with expr1 when( expr2 )`  returns value of `expr1` to caller function  when `expr2` evaluate to true otherwise next line.

Then these code are equals to:

 >  >     function main_function()
 >  >     {
 >  >         $result = calculate($var);
 >  >         if ($result !== null)
 >  >             return $result;
 >  > 
 >  >         /* do other important stuff */
 >  >     }
 >  > 

function main_function() 
{
   escape with $result when(   $result = calculate($var) );

  /* do other important stuff */
}


 >  >     function foo($bar)
 >  >     {
 >  >         if ($bar === 1)
 >  >             return;
 >  > 
 >  >         if ($bar === 666)
 >  >             delete_everything();
 >  >     }


function foo($var) {
  escape when( $bar === 1 ||  $bar !== 600 );

  delete_everything();
}