> On Dec 15, 2020, at 12:18 PM, Larry Garfield <larry@garfieldtech.com> wrote:
>
> On Tue, Dec 15, 2020, at 3:00 AM, Nikita Popov wrote:
>> On Mon, Dec 14, 2020 at 6:34 PM Larry Garfield <larry@garfieldtech.com>
>> wrote:
>>
>>> I present to Internals this tiny RFC to follow up on the match()
>>> expression RFC from earlier in the year. There was solidly positive
>>> support for this shortcut previously but it was removed for simplicity at
>>> the time, with the intent to bring it back later. It's now later.
>>>
>>> https://wiki.php.net/rfc/short-match
>>>
>>> --
>>> Larry Garfield
>>> larry@garfieldtech.com
>>>
>>
>> Just like Sara, I'm not strongly opposed to this, but I'm also not sure
>> this is worthwhile. Writing "match (true) {" instead of "match {" is
>> not
>> particularly tedious when compared to the size of the remaining structure.
>> Writing "match (true) {" has the advantage of being more explicit about
>> what this actually does, namely a "true ===" comparison. If it is omitted,
>> a reasonable person might think that
>>
>> match {
>> preg_match(...) => ...
>> }
>>
>> is going to do something sensible, like it would if placed inside an
>> "if()". But it does not, as preg_match() returns 1, not true, and as such
>> the match arm will never be taken. This is more obvious when the value that
>> is being compared against is explicitly given.
>>
>> Of course, with "match {" being a dedicated syntax, we could make it a
>> TypeError to use a non-bool match arm...
>>
>> Regards,
>> Nikita
>
> Hm. preg_match() is the first example I've seen that makes me think the weak comparison
> may have value in this case. I will have to consider that and discuss with Ilija a bit. (Since
> match was his addition and relates to the ongoing enum work.) I'd also have to figure out how
> best to handle that, too, since it's a deeper change. Whee!
>
> Several people have mentioned also short-circuiting switch the same way. I am not opposed, and
> honestly don't feel too strongly about it either way. On Twitter, someone suggested also short
> circuiting while (true) the same way; I don't know how useful that is, but I acknowledge the
> consistency argument. I'm happy with whatever the consensus is on both points.
Allowing "switch {...}" to represent "switch (true){...}" might not actually be
consistent. Since switch/case does a loose equality check some people get confused when using it
with booleans:
https://stackoverflow.com/questions/8829229/why-switchtrue-in-php-with-a-strange-logic
<https://stackoverflow.com/questions/8829229/why-switchtrue-in-php-with-a-strange-logic>
If we allow "switch {...}" to represent "switch (true){...}" then the value
switch compares will be hidden and less obvious to a developer if they are forgetting to consider
switch's evaluation behavior. For some people this would increase the WTF factor.
#fwiw
-Mike
P.S. OTOH allowing "while(true){...}" to be represented as "while{...}" would
be great since AFAIK "while{...}" would not violate the principle of least surprise.