Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109601
To: internals@lists.php.net
References: <CAPyj-LDfdATXFD+dc5AY9EqWWxgf8LP1joD2fzvm==1gUoN35A@mail.gmail.com>
 <C3F55856-66AF-44F5-8F43-8E41FA8DC6E8@gmail.com>
 <CAPyj-LBt_Cq+qa49+H3Tav+uepSJ23+TPg_JN5DofGC7y8fnoQ@mail.gmail.com>
Message-ID: <6aebe21d-2137-885e-5ee9-99d4f917a7f9@gmail.com>
Date: Sun, 12 Apr 2020 23:03:53 +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: <CAPyj-LBt_Cq+qa49+H3Tav+uepSJ23+TPg_JN5DofGC7y8fnoQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [DISCUSSION] Match expression
From: rowan.collins@gmail.com (Rowan Tommins)

On 12/04/2020 21:16, Ilija Tovilo wrote:
>
>> Can match arms contain other flow control, such as "return" or "continue"?
> Yes and yes. They behave exactly the same as in the switch. This
> should definitely be described in the RFC.


You didn't quote the second part of that question, which admittedly was 
a bit rhetorical, but important: allowing these rules out using either 
of those keywords in future extensions of this syntax. That means if we 
want to add a way to get a value out of a statement block, we can't use 
"return"; and if we want to add explicit fallthrough, we can't use 
"continue".

Also note that in switch, "continue" and "break" are actually synonyms, 
both jumping to the end of the switch block (see also 
https://wiki.php.net/rfc/continue_on_switch_deprecation). I'm not sure 
that's actually all that intuitive or useful in the proposed match 
statement.


>> Can I mix a bare value and a block as arms of the same match, or does the whole construct need to be in either "expression form" or "statement form"?
> Yes, you can mix blocks and expressions given you don't use the return
> value of the whole match expression.


Again, you skipped the second part of the question - will this make 
sense to users? What error message will they get if they write this:

$x = match($y) { 1 => "Hello", 2 => "Goodbye", 3 => { throw new 
Exception; } };

(If https://wiki.php.net/rfc/throw_expression passes, then "3 => throw 
new Exception" without the braces will presumably be valid, but that 
just makes it even more confusing, IMO.)


>> Can I omit the trailing semicolon even in "expression form"
> Yes.


So this would be valid PHP?

$x = match($y) { 1 => "Hello", 2 => "Goodbye" } echo $y;


> To clarify what's going on here: There's no statement variant of
> the match expression [...]


I don't think users will see it that way. An "expression" where you 
can't use the result (but can use flow control like "throw" and 
"return") feels very much like a statement, regardless of how the parser 
defines it.


> ... because I noticed that I kept forgetting to add it in my tests.


I think needing to add a special case to the grammar is a sign that the 
proposed syntax doesn't fit well with the rest of the language. Did you 
ever forget to put the semicolon when using it in expression context, or 
only when using statement blocks?


> As mentioned in my announcement IMO it doesn't make sense criticizing
> the switch statement but then not offering an alternative.


I don't think this is true. If you were proposing "foreach", you might 
criticize the "for" statement, but that doesn't mean you'd extend 
"foreach" so that it could replace every single "for" statement.

To reiterate, I think the match expression - with no statement blocks - 
stands up really well as a replacement for those switch statements where 
you're deciding on a value, and for nested ternaries (which are pretty 
much unused in PHP due to the broken precedence).

Other proposals can replace other uses of switch, or switch can live on 
with more limited use - after all, we even have a "goto" statement in 
PHP, for those rare occasions where *none* of the built-in flow control 
is good enough.


To respond to something you said to Larry:

> People can't be forced into
> writing clean code and my fear here is that they will just revert back
> to using what is more convenient.


That's their loss! Whether or not "match" supports blocks, some people 
won't use it, just as some people write unnecessarily complicated if 
statements because they don't spend the time structuring them with 
elseif or switch.

My concern is that if match supports blocks, but the syntax and 
behaviour is unintuitive, we'll be stuck with another feature that 
nobody likes very much but we can't easily replace. Worse, the RFC might 
lose support based on that part, and we'd miss out on getting a really 
nice new expression.


Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]