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....@gmail.com> escreveu: > On Sun, May 10, 2020 at 5:49 PM Ralph Schindler <ra...@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 >
