Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110117
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
In-Reply-To: <CANeKSiSCKw9tncxAzxGR30NrqO61cyBscZ1PNZSLE1dX7esO3Q@mail.gmail.com>
Date: Sun, 10 May 2020 16:00:16 -0400
Cc: Ralph Schindler <ralph@ralphschindler.com>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <5780912D-2926-4381-8B40-FF4353140014@zort.net>
References: <f9109d72-f3d3-5b12-16bb-9ec03d164cf4@ralphschindler.com>
 <E4B20C3D-1C1F-4F10-A7BF-42CFFEB07196@zort.net>
 <CANeKSiSCKw9tncxAzxGR30NrqO61cyBscZ1PNZSLE1dX7esO3Q@mail.gmail.com>
To: Benas IML <benas.molis.iml@gmail.com>
Subject: Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause
 Syntax
From: jbafford@zort.net (John Bafford)

Benas,

> On May 10, 2020, at 15:19, Benas IML <benas.molis.iml@gmail.com> =
wrote:
>=20
> Hello,
>=20
> I think that we SHOULD not introduce a new keyword (e. g.  guard) =
since that
> would be a "major major" backwards incompatibility. "Guard" is a =
really generic
> word and a great example of that is Laravel and their authentication =
guards.
>=20
> In general, I don't think that early returns require a seperate syntax =
and/or
> block statement since a simple `if (...) { return; }` is already =
sufficient
> enough.
>=20
> Best regards,
> Benas Seliuginas


I think there's three main reasons for guard, as opposed to if:

1) It further and clearly establishes intent: if you see guard, you have =
more information about the programmer's intent and what the code will =
actually do.
2) It prevents having to negate the condition: guard (is valid) else, =
instead of if (not valid) then; negations impose additional cognitive =
load when attempting to understand code, especially if your condition =
already has a negation.
3) The language provides a guarantee that if the guard condition is not =
met, execution can not proceed past the else clause. This helps prevent =
accidental fall-through, such as if you wrote: if(!$valid) { =
terminate(); } expecting it to end execution (e.g. via a throw or exit), =
but for some reason it failed to do so.

To take an idea from Ralph's original proposal, perhaps some syntax like =
"if guard (condition) else ...". In this context, guard could not =
possibly be confused with a function from the parser's point of view, =
instead serving as an intent modifier to if.

-John