Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110112
MIME-Version: 1.0
References: <f9109d72-f3d3-5b12-16bb-9ec03d164cf4@ralphschindler.com>
In-Reply-To: <f9109d72-f3d3-5b12-16bb-9ec03d164cf4@ralphschindler.com>
Date: Sun, 10 May 2020 20:47:45 +0200
Message-ID: <CAF+90c8CbXYumgz1Jzujo0u9wOeX_qxaizAMDykCztZ=ChZ7_g@mail.gmail.com>
To: Ralph Schindler <ralph@ralphschindler.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008ae6c105a54fab3d"
Subject: Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause Syntax
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000008ae6c105a54fab3d
Content-Type: text/plain; charset="UTF-8"

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

--0000000000008ae6c105a54fab3d--