Newsgroups: php.internals,php.internals
Path: news.php.net
Xref: news.php.net php.internals:110209 php.internals:110210
Date: Tue, 19 May 2020 08:53:46 +0200
To: "Peter Stalman" <sarkedev@gmail.com>
Cc: "PHP internals" <internals@lists.php.net>
Message-ID: <1722bb5aeba.efaf5e2a253261.3998926174950017220@manuelcanga.dev>
In-Reply-To: <CAPrKfG6tr6MmLCBBds7nSUnc7SUno+uEPaAcBzRFhWw+VPAttw@mail.gmail.com>
References: <f9109d72-f3d3-5b12-16bb-9ec03d164cf4@ralphschindler.com> <85C8412B-B04A-4853-8C4C-E270FCB35EEE@getmailspring.com> <CAPrKfG6tr6MmLCBBds7nSUnc7SUno+uEPaAcBzRFhWw+VPAttw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Importance: Medium
User-Agent: Zoho Mail
Subject: Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause
 Syntax
From: php@manuelcanga.dev (Manuel Canga)


Hi, Internals,



 ---- En dom, 17 may 2020 06:33:51 +0200 Peter Stalman <sarkedev@gmail.com>=
 escribi=C3=B3 ----
 > A few thoughts:
 >=20
 >=20
 > 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.
 >=20
 >=20
 > 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.
 >=20
 >=20
 > 3. As Thomas Lamy mentioned, I too would prefer a single keyword.
 > Consider the following two examples:
 >=20
 >     function foo($bar)
 >     {
 >         if ($bar =3D=3D=3D 1)
 >             return;
 >=20
 >         if ($bar =3D=3D=3D 666)
 >             delete_everything();
 >     }
 >=20
 >     function foo($bar)
 >     {
 >         if ($bar =3D=3D=3D 1)
 >             return
 >=20
 >         if ($bar =3D=3D=3D 666);
 >             delete_everything();
 >     }
 >=20
 > 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.
 >=20
 >=20
 > 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.
 >=20
 > Consider the following (a bit contrived, but I hope you get the point):
 >=20
 >     function main_function()
 >     {
 >         $result =3D calculate($var);
 >         if ($result !=3D=3D null)
 >             return $result;
 >=20
 >         /* do other important stuff */
 >     }
 >=20
 >     function main_function()
 >     {
 >         ifnotnullreturn calculate($var);
 >=20
 >         /* do other important stuff */
 >     }
 >=20
 > 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.
 >=20
 >=20
 > 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.
 >=20
 >=20
 > Thanks,
 > Peter
 >=20

I agree.=20

=C2=BF 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 funct=
ion  when `expr2` evaluate to true otherwise next line.



Regards
--
Manuel Canga