Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109941
MIME-Version: 1.0
Date: Thu, 30 Apr 2020 11:49:51 +0300
Message-ID: <CABAhh3GKb8+zMpZRYEMeZ2c3J=ztXbXsZmsp9oVVPdS4LN=Sdg@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: someniatko@gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KHQvtC80L7Qsg==?=)

Hi!

I am quite new to the internals list, but wanted to say a word, to
maybe lit some light on the discussion, for you to be able to look at
it from slightly another angle.

I have noticed this whole thread arguing whether it is required or not
to support `match` keyword in an if-else-ish control-flow manner: in
other words, support not only expressions in the `match` branches, but
also arbitrary statements.

As we know, each PHP expression can be used as a statement. We also
know that large subset of practically used statements (function call,
variable assignment) can be implemented in expression form. This
subset also tends to enlarge: recently throwing an exception became
expressible in expression form.

This means we can write code like this:
```
match($state) {
    State::VALID => processFurther(),
    State::PENDING => $isPending = true,
    State::INVALID => throw new \RuntimeException(),
};
```

IMO this covers vast majority of use-cases of the PHP statements.

The cases which are not covered are:
1) statements which cannot be expressed as expressions: `echo`, `unset`.
2) control flow which requires usage of more than one statement, e.g.
assigning two variables, or calling two functions with void return
type one after another one etc.

I would like to emphasize that this problem is the same as short
closures problem, and should be treated at the same time. Problem no.
1 could be solved by allowing statements like `unset` to be used in
expression form, if it's feasible. Problem no. 2 could be addressed by
allowing "complex" expressions consisting of, potentially, few
statements, language-wide, solving the issue both for short closures
and for `match`, if it is really needed though. Anyway it is possible
to use in-place old-school closure as a temporary workaround.

> 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.

IMO a good language should enforce better quality. Especially when we
talk about new language constructs. Short closures already enforce
SRP, at least in closures world. Also, those people who would benefit
from less boilerplate which match in expression-only form provides,
are usually the people who care about code quality. Those who you
mention as "average code quality" would not bother with new syntax at
all and would still prefer old-school switch to do whatever level of
entanglement they had used to. If, though, you insist on match to
completely replace old switch, as well as short closures to replace
traditional ones, you may want to consider to solve "complex
expression" problem once for both of them, and move this out of scope
of this RFC. This will allow for gradual improvement of the language,
from which both parties will benefit: those who want to write clean
code (which is usually split up in functions such that match can be
used straight away with only one expression per arm), and those who
use complex logic in switches - will be able to do the same in match,
but later, when "complex expressions" are implemented.

someniatko