Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109868
MIME-Version: 1.0
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>
In-Reply-To: <5ea6e4b0.1c69fb81.cf3ee.2bbfSMTPIN_ADDED_MISSING@mx.google.com>
Date: Tue, 28 Apr 2020 10:48:28 +0200
Message-ID: <CAF+90c8LGLRz5zkNKAQ=c5SiR-ig5hh_HHWQXaS2JAeMG85-Eg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003324a505a455e662"
Subject: Re: [PHP-DEV] [VOTE] match expression
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000003324a505a455e662
Content-Type: text/plain; charset="UTF-8"

On Mon, Apr 27, 2020 at 3:57 PM Andrea Faulds <ajf@ajf.me> wrote:

> Hi,
>
> I share Dan's reasons for voting against. I don't think things should go
> to a vote before the dust has settled.
>
> Regards,
> Andrea Faulds
>

Similar sentiment here. I don't think the concept has been explored
sufficiently.

Many people in the voting thread are calling for supporting match
expressions only (without support for either statement form, or support for
block expressions). The RFC motivates the match construct as an improved
replacement for switch, which is type-safe, exhaustive and has no
fallthrough gotchas. If we limit match to returning simple expressions
only, is it still a viable replacement for switch?

I've looked at a sample of ~50 switches randomly picked from popular
composer packages, the list can be found here:
https://gist.github.com/nikic/fc225f02ea76c02e669a598cfc471b83 I've
classified these according to whether the switches could be rewritten as a
match if it only supports expression, but not statement form. What I was
looking for here was the ability to more or less directly translate,
without having to do major refactoring first. Results:

2595: no (only with block expression support)
8337: no (only with block expression support)
2115: no
7109: no (only with block expression support)
6564: no
7786: no (only by returning a pair, and only realistic with block
expression support)
2609: yes
7450: no (only by returning a triple, and only with block expression
support)
5338: no
 567: no
3376: yes (but weird stylistically)
2850: no
2635: yes
  61: no
6562: no
2354: yes
 522: no
4972: yes
8179: no
6080: yes
5997: yes
6758: yes
6718: no (only with block expression support)
1451: maybe
9152: yes
4192: no
4099: no
6773: yes
2727: yes (but weird stylistically)
6779: yes
2710: no
 149: yes
7501: no
1197: no (only with block expression support)
6845: yes
6610: no
1088: yes (but weird stylistically)
2806: yes
3393: no
8361: no (only by returning a pair, and only with block expression support)
4473: no
8543: no
8792: no (only with block expression support, maybe)
8776: no
1165: yes
8388: yes
8294: no
3840: yes
3587: yes
6428: (empty switch)
8324: no
1280: no
2023: yes
8084: no (maybe with block expression support)

Of the switches I looked at, 31 cannot use match in single-expression form,
while 21 can.

Is match intended as a replacement for switch? Or is intended to replace
the ternary operator? Do we want people to be able to convert switches to
matches without much hassle, or is this only intended for a specific
subset? I'm not quite clear on what "match" is intended to be, and I think
different people in this discussion have rather different views on this.

Regards,
Nikita

--0000000000003324a505a455e662--