Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102281
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain telia.com designates 81.236.60.156 as permitted sender)
To: Rowan Collins <rowan.collins@gmail.com>,
 Nikita Popov <nikita.ppv@gmail.com>, Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>
References: <CAESVnVqm3tVt53bQfxOpQcOMf_2fXhnu9y+42trTfv7zNMONHw@mail.gmail.com>
 <CAF+90c-HGB-2MbdrCYuQNrNYR4EJ9hAeFaKTW-sh1kwboDd0Kg@mail.gmail.com>
 <CALKiJKpAHmWkJv9=evyr+Bw_9nEV1tjm5xGq=bG0X_RiXgHHeQ@mail.gmail.com>
Message-ID: <bf35af18-42e5-3fa8-6411-b3b384a7038e@telia.com>
Date: Sat, 16 Jun 2018 16:45:32 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <CALKiJKpAHmWkJv9=evyr+Bw_9nEV1tjm5xGq=bG0X_RiXgHHeQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: sv
Subject: Re: [PHP-DEV] Strict switch statements
From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)

Den 2018-06-14 kl. 11:21, skrev Rowan Collins:

> On 14 June 2018 at 09:35, Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> On Thu, Jun 14, 2018 at 6:53 AM, Sara Golemon <pollita@php.net> wrote:
>>
>>> Just for casual discussion at this point:
>>> https://github.com/php/php-src/pull/3297
>>>
>>> switch ($a) {
>>>    case FOO:
>>>        // Works exactly as current behavior.
>>>        break;
>>>    case == FOO:
>>>       // Nearly identical, though not using the ZEND_CASE optimization.
>>>       // Can probably make this equivalent to `case FOO`, but it felt
>>> like an interesting direction.
>>>       break;
>>>    case === FOO:
>>>       // Only triggers if `$a === FOO`, no type juggling
>>>       break;
>>> }
>>>
>>> Love it? Hate it? See obvious flaws?  The implementation is just a
>>> rushed proof of concept, not something I've labored over, it may well
>>> have bugs.  Certainly wouldn't target anything earlier than 7.4, if at
>>> all.
>>>
>> I like the general idea here (switch with strict type comparison), but not
>> super fond of the particular syntax and implementation.
>>
>> I think if people want to use strict matching, they'll quite likely want to
>> have it on all cases. Something like "strict switch ($expr) {}" or "switch
>> strict ($expr) {}" or "switch (strict $expr) {}" or "switch ($expr) strict
>> {}" or "switch ($expr) { strict; }" or whatever would be preferable in that
>> case.
>>
>
> For ages, I've had an idea along these lines kicking around.  Like Nikita,
> I was assuming that all branches would want strict comparison or none, so
> was thinking of putting the operator at the top, something like "switch
> ($expr) use (===)". I figured it could then be extended so the "===" could
> be substituted for any binary operator; for instance, you could match
> values into ranges with "switch ($score) use (>=)".
>
> That said, I can see an attraction in a form with the operator on the
> branch, if operators other than "==" and "===" are supported; for the range
> example, it might be handy to have cases for ">= 50", "> 0", and "=== 0".
>
> I prefer reusing "===" in some way over the word "strict", even if no other
> operators are supported, because "strict" could mean a number of things -
> "strictly no fall-throughs", for instance - and I think that could cause
> confusion (people already expect "strict types" to mean more than it does).
>
> Regards,

Yup, I also like this idea very much. Using the === syntax is a clear
message on what's it all about. Having the ability to extend it to
other operators is also interesting, e.g. !== & !=.

Another point is that by keeping switch keyword it would be relatively
easy to upgrade legacy code, making it more robust.

Of course there is a use for a new keyword like match extending the
functionality even more. Maybe we can have both?

I'm thinking if one should be able to have like:
switch ($a)  {
     case === FOO:
         break;
     case !== BAR:
         break;
}
or:
switch ($a) with !== {
     case FOO:
         break;
     case BAR:
         break;
     default:
         break;
}
or:
switch ($a, ===)  {
     case FOO:
         break;
     case BAR:
         break;
}

r//Björn Larsson