Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109869
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 10:23:50 +0100
Message-ID: <CALKiJKqbxJnMH6pWs3Nc1T9JuYpHnfK3iQHkDASkuWWz5=MTUA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006ae38405a4566418"
Subject: Re: [PHP-DEV] [VOTE] match expression
From: rowan.collins@gmail.com (Rowan Tommins)

--0000000000006ae38405a4566418
Content-Type: text/plain; charset="UTF-8"

On Tue, 28 Apr 2020 at 09:48, Nikita Popov <nikita.ppv@gmail.com> wrote:
> 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?
[...]
> Is match intended as a replacement for switch? Or is intended to replace
> the ternary operator?


Two thoughts on this:

1) 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. Instead, it's seen as an extra tool in the chest,
with its own strengths and weaknesses. I think it's better to focus on what
the use cases are, rather than how they'd currently be written. In other
words, the fact that it's not a straight replacement for switch may be a
feature, not a bug.

2) As a thought experiment, imagine splitting the current proposal into
two: a new conditional expression, and a new control-flow statement. To me,
the syntax currently proposed works really nicely for the conditional
expression; 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. That's why it feels
more natural to suggest dropping the statement and keeping the expression
than the other way around.

Regards,
-- 
Rowan Tommins
[IMSoP]

--0000000000006ae38405a4566418--