Hi Ralph,
> On May 10, 2020, at 11:49, 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!
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
