Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109932
To: internals@lists.php.net
References: <CAPyj-LDo0AafB9FZoxUHU35Y7PAU+DYb4qGm+KV2-eF5KvNmng@mail.gmail.com>
 <CA+kxMuRo-oVGYCuFRsB8mag=x6W57Yy0CmY6rXeRQ55pKqLsew@mail.gmail.com>
 <5ea6e4b0.1c69fb81.cf3ee.2bbfSMTPIN_ADDED_MISSING@mx.google.com>
 <CAF+90c8LGLRz5zkNKAQ=c5SiR-ig5hh_HHWQXaS2JAeMG85-Eg@mail.gmail.com>
 <CAPyj-LDGip777McwcuVGMm--UryD0r_U4A-NJP60w74sVsKpRg@mail.gmail.com>
 <CALKiJKq1EX5Zdw2a12=FESd8=yFqtuDt7ofovR0vLov8=ztVAg@mail.gmail.com>
 <VI1PR02MB47035BF9579880C7FDB470F3E2AC0@VI1PR02MB4703.eurprd02.prod.outlook.com>
 <CALKiJKpEOb7Txvq5n7k9=1ga-sdPoZG3xWjiWxJSCaNpoiGzjg@mail.gmail.com>
 <969c6150-a084-48c0-ae8f-b8043dce321d@www.fastmail.com>
Message-ID: <6f55fbce-904b-910f-35d1-c6d91504d01f@gmail.com>
Date: Wed, 29 Apr 2020 18:22:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <969c6150-a084-48c0-ae8f-b8043dce321d@www.fastmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [VOTE] match expression
From: rowan.collins@gmail.com (Rowan Tommins)

On 29/04/2020 01:26, Larry Garfield wrote:
> To that end, I'm going to refer to them as rustmatch (an expression that only supports expressions and returns things; basically a fancier alternative to ternary) and switchtng (a procedural branching statement that is basically switch but with the lessons of the 40 years since C switch was invented, which PHP blindly inherited) to avoid privileging one or the other.


I like the codenames. :)

Thinking about it, I think the "switchng" syntax can be even more 
conservative. The RFC lists four issues with switch, of which three 
would be applicable to a "switchng" RFC:

1. Type coercion
2. Fallthrough
3. Inexhaustiveness

For #1, the only thing we need is some way to opt into "strict mode" on 
the switch statement, and have the comparisons handled by === rather 
than ==. That could be as simple as writing "switch strict" instead of 
"switch".

For #2, the problem is that fallthrough is implicit where no "break" is 
present, so what if we just said that reaching another "case" statement 
was a runtime error in a switchng statement? That would mean any 
existing switch statement that didn't use fallthrough could be 
"upgraded" without changing its body at all.

We could allow multiple case labels with no statements between, allowing 
for the common scenario of multiple conditions running identical code. 
Alternatively (or as a separate enhancement) we could allow 
comma-separated lists in case blocks (on both normal switch and switchng).

For other cases of fallthrough, we could add a new keyword (or recycle 
"continue") to explicitly go to the next case. That could even be left 
to "Future Scope", because anyone wanting it can always "downgrade" to 
the version with implicit fallthrough.

Finally, #3 can be part of the same "strict mode", with one of two 
behaviours:

a) Make a switchng with no "default:" clause a compile-time error
b) Make a switchng which doesn't match any case a run-time error, 
effectively adding an implicit clause of "default: throw new Error(); 
break;"


So our shiny new "switchng" statement would look ... exactly the same as 
a normal switch statement, but with one new keyword, and the ability to 
throw two new errors.


Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]