Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109870
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> <CAF+90c8LGLRz5zkNKAQ=c5SiR-ig5hh_HHWQXaS2JAeMG85-Eg@mail.gmail.com>
In-Reply-To: <CAF+90c8LGLRz5zkNKAQ=c5SiR-ig5hh_HHWQXaS2JAeMG85-Eg@mail.gmail.com>
Date: Tue, 28 Apr 2020 12:18:42 +0200
Message-ID: <CAPyj-LDGip777McwcuVGMm--UryD0r_U4A-NJP60w74sVsKpRg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [VOTE] match expression
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Nikita

Thank you for your analysis. That's something I should've done as part
of the RFC.

I can only share my personal motivation for creating this RFC. Some
people will disagree.

> Is match intended as a replacement for switch?

To me, match is primarily a switch alternative with safer semantics.
While it is very nice that match evaluates to the executed arm I think
statement matches would be more common and more useful. Your analysis
seems to align with that.

> If we limit match to returning simple expressions
> only, is it still a viable replacement for switch?

I don't think so. Of course, some people might argue that the switch
is fine and doesn't need a replacement which is an entirely valid
viewpoint. However, that would directly contradict most of the
arguments made in the RFC. If the switch is fine adding another
alternative with different semantics is questionable. If the issues
listed in the RFC are valid IMO this RFC only makes sense supporting
blocks.

> Of the switches I looked at, 31 cannot use match in single-expression form,
> while 21 can.

I think that sums it up nicely. Let's also remember that these are
popular, well maintained repositories and probably don't reflect the
average code quality very well.

Let me also address Rowans comment:

> Why does it need to *replace* anything? Introducing switch to a language
> isn't usually considered a replacement for if-elseif-else, even though the
> usage overlaps heavily.

The if statement doesn't have (most of) the issues stated in the RFC.
Match is a direct response to the flaws of the switch. Without blocks
match won't actually be usable in most of these cases and you'll be
stuck with switch and its flaws. Again, you can argue the switch
doesn't have flaws but then the whole RFC doesn't make any sense.

> for the control-flow statement, it feels awkward and not in
> keeping with the rest of the language. If they were separate proposals, the
> statement would probably end up looking very different.

Can you elaborate? If I made a proposal exclusively for match
statements the syntax would be exactly equivalent.

Ilija