Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109495
To: internals@lists.php.net
References: <CAPyj-LBfSHyF-_zxFX9UScrmKc2Jo2G-GUwQ24fTqqyzxEc+kQ@mail.gmail.com>
 <7E3BE38A-1DAB-4523-871A-7AAEE0E697C4@gmail.com>
Message-ID: <76ebf15d-5f4f-f5a9-365c-d2e829c9961f@gmail.com>
Date: Wed, 1 Apr 2020 12:04:31 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <7E3BE38A-1DAB-4523-871A-7AAEE0E697C4@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC][POLL] Switch expression
From: rowan.collins@gmail.com (Rowan Tommins)

On 01/04/2020 09:56, Rowan Tommins wrote:
> 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.


To expand on this a bit, if the aim is "a switch statement, but usable 
as an expression", then it would make sense to start with an identical 
syntax, and make only those changes needed to meet that aim.

So, given the following example from the RFC:

switch ($x) {
     case 0:
         $y = 'Foo';
         break;
     case 1:
         $y = 'Bar';
         break;
     case 2:
         $y = 'Baz';
         break;
}

The starting point would be to move the assignments and nothing else:

$y = switch ($x) {
     case 0:
         'Foo';
         break;
     case 1:
         'Bar';
         break;
     case 2:
         'Baz';
         break;
}

That looks a little odd, because the result expressions are formatted as 
statements, so we could maybe combine them with the break keyword:

$y = switch ($x) {
     case 0:
         break 'Foo';
     case 1:
         break 'Bar';
     case 2:
         break 'Baz';
}

We could then bikeshed whether to swap out "break" for "return" or 
"yield", but the result would look and act like an expression version of 
the switch statement. It could even have other statements between the 
"case" and "break" lines, and all the normal fallthrough behaviour.

The other issues discussed in your RFC - fallthrough, inexhaustiveness, 
type coercion - are valuable things to discuss, but each one takes this 
further away from being a "switch expression", and into being "a new 
value-matching expression". As I said in my last e-mail, I don't think 
that's a bad thing; I really like the proposed syntax, as a new 
construct for picking one of a set of expressions, and would be happy to 
see the RFC re-focussed in that direction.


Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]