Re: Proposal For Return-If / Early Return / Guard Clause Syntax
| From: | Manuel Canga | Date: | Tue, 19 May 2020 07:04:43 +0000 |
| Subject: | Re: Proposal For Return-If / Early Return / Guard Clause Syntax | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-110211@lists.php.net to get a copy of this message | ||
---- 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();
}