> On Dec 15, 2020, at 12:18 PM, Larry Garfield <la...@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 <la...@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
>>> la...@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.
