Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112352
MIME-Version: 1.0
References: <CAEsg9X1JmNm22NSi=q6=oZD2=WtZy1CwWRCYUW5NrPG6AjBP7w@mail.gmail.com>
 <CAF+90c_XU1O_8Cs4_wsQ9-Bju2HtVtp16t8xBPN5Zuq=njH_2g@mail.gmail.com> <5ba9d3db-7c4c-4929-ad22-65727141a52d@www.fastmail.com>
In-Reply-To: <5ba9d3db-7c4c-4929-ad22-65727141a52d@www.fastmail.com>
Date: Tue, 1 Dec 2020 20:30:27 +0100
Message-ID: <CAF+90c85X9fGq6mekix1pnjtx2iNrVTn859tmdPQpsibwtt7hw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ab30a105b56c297a"
Subject: Re: [PHP-DEV] Strict switch
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000ab30a105b56c297a
Content-Type: text/plain; charset="UTF-8"

On Tue, Dec 1, 2020 at 7:57 PM Larry Garfield <larry@garfieldtech.com>
wrote:

> On Mon, Nov 30, 2020, at 9:09 AM, Nikita Popov wrote:
> > On Thu, Nov 26, 2020 at 5:39 PM David Rodrigues <david.proweb@gmail.com>
> > wrote:
> >
> > > Hello!
> > >
> > > With PHP 8 we have match(), that is a switch strict expression-like.
> But
> > > strict is not strict, and it could cause confusion because switch() and
> > > match() are pretty similar.
> > >
> > > I believe that this has already been discussed, but it would be
> interesting
> > > to re-evaluate the possibility of a strict() with support for strict.
> > >
> > > In order not to generate BC, my suggestion is to attach a specific
> keyword
> > > for this purpose, or a similar alternative.
> > >
> > > (0) switch(8.0) { case '8.0'; return 'no'; case 8.0: return 'yes'; }
> // no?
> > >
> > > (1) strict switch(8.0) { case '8.0'; return 'no'; case 8.0: return
> 'yes'; }
> > > // yes
> > > (2) switch strict(8.0) { ... } // yes
> > > (3a) switch(8.0, true) { ... } // yes
> > > (3b) switch(8.0, strict: true) { ... } // yes (named argument)
> > >
> > > Or then in the "case":
> > >
> > > (4) switch(8.0) { strict case 8.0: ... } // yes
> > > (5) switch(8.0) { case strict 8.0: ... } // yes
> > >
> > > Or allowing operators (this would be the most flexible way, as it would
> > > allow for a number of other features):
> > >
> > > (6) switch(8.0) { case === 8.0: ... } // yes
> > >
> > >
> > >
> > > Atenciosamente,
> > > David Rodrigues
> > >
> >
> > I think the better direction here would be to improve match() such that
> it
> > can replace more of the current switch use cases. If match supported
> block
> > expressions, then most uses of switch() could use match() instead, and as
> > such make use of the strict comparison semantics. Only switches that make
> > use of non-trivial fallthrough behavior could not be easily expressed
> using
> > match.
> >
> > Nikita
>
> Disagree.  switch is a procedural logic flow control.  match is an
> evaluation expression.  Things like fallthrough do not belong there, as it
> mushes expressions together in weird ways.  match is lovely because its
> logic flow is simple and predictable.  We should keep that.
>

Sorry if the phrasing was unclear. I'm not suggesting to add fallthrough
support. Fallthrough was mentioned as the one thing that match cannot and
should not support by design.

I'm referring to support for non-trivial expressions, aka blocks. Say, the
ability to split up a long expression by using a meaningful temporary
variable. Block support is sufficient to cover *most* switch use-cases,
obviating the need to introduce a new switch variant.

Regards,
Nikita

--000000000000ab30a105b56c297a--