Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109494
Date: Wed, 01 Apr 2020 09:56:49 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <CAPyj-LBfSHyF-_zxFX9UScrmKc2Jo2G-GUwQ24fTqqyzxEc+kQ@mail.gmail.com>
References: <CAPyj-LBfSHyF-_zxFX9UScrmKc2Jo2G-GUwQ24fTqqyzxEc+kQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: internals@lists.php.net
Message-ID: <7E3BE38A-1DAB-4523-871A-7AAEE0E697C4@gmail.com>
Subject: Re: [PHP-DEV] [RFC][POLL] Switch expression
From: rowan.collins@gmail.com (Rowan Tommins)

On 31 March 2020 19:50:59 BST, Ilija Tovilo <tovilo=2Eilija@gmail=2Ecom> wr=
ote:
>There's been a fundamental disagreement on what the switch expression
>should actually be=2E Due to the conflicting feedback I no longer know
>how to proceed=2E

I think this confusion is there in your proposal, not just in people's res=
ponses to it=2E=20

In the new poll, you say this:

> The question seems to be if this new construct
> should be a variation of the switch to make it
> usable as an expression (like the RFC currently
> suggests)

But the introduction of the actual RFC doesn't even mention the expression=
 part, only that you want to solve some of the problems of the current stat=
ement:

> The switch statement has some long-standing
> issues that we're going to look at in this RFC=2E=20

You then go onto describe 4 problems, and propose a new syntax that solves=
 3 of them, with only the type coercion part retaining the switch statement=
's behaviour=2E

I don't think people are saying they *want* the proposal to be more of "an=
 alternative to the switch statement that fixes all the issues mentioned in=
 the RFC", they're saying that what you've currently proposed *is* that rep=
lacement=2E If that's the intention, using a new keyword would make sense=
=2E If the intention is to make this feel like an expression version of the=
 switch statement, then making it look more similar would make sense=2E

I think it's ultimately up to you which direction you want to take the pro=
posal, but you should pick one and follow it through=2E=20

Personally, I think changing the keyword to "match", and possibly using st=
rict comparison, would make a compelling feature=2E I don't think this part=
 would be needed or desirable:

> Each case can contain a single expression, or a
> block with a statement list if the expression
> result is discarded=20

I think it's perfectly fine to have a match expression that's built only f=
rom expressions=2E If someone wants flow control, they can use other featur=
es, the new syntax doesn't need to do everything=2E

Regards,
Hi Ilija,
--=20
Rowan Tommins
[IMSoP]