Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109703
MIME-Version: 1.0
References: <CAPyj-LDfdATXFD+dc5AY9EqWWxgf8LP1joD2fzvm==1gUoN35A@mail.gmail.com>
In-Reply-To: <CAPyj-LDfdATXFD+dc5AY9EqWWxgf8LP1joD2fzvm==1gUoN35A@mail.gmail.com>
Date: Sun, 19 Apr 2020 12:38:49 +0200
Message-ID: <CAJmjfvUQQCDcQ-pJrY6Vgumjb3Pp22qLCU2+SgZ0Q0EPmutJ_A@mail.gmail.com>
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [DISCUSSION] Match expression
From: jakob@givoni.dk (Jakob Givoni)

Hi Ilija,

On Sun, Apr 12, 2020 at 2:16 AM Ilija Tovilo <tovilo.ilija@gmail.com> wrote:
>
> I'd like to announce the match expression RFC that replaces the switch
> expression RFC I announced a few weeks ago.
> New: https://wiki.php.net/rfc/match_expression
> Old: https://wiki.php.net/rfc/switch_expression

I know I'm a little late to the game and sorry for that, but I didn't
have time to thoroughly read the proposal earlier.

And again, sorry if it's just me going "blind" but I can't find
anything explaining what will happen if there is more than one
matching arm?

I imagine that since the case of no matching arms will throw an
UnhandledMatchError exception, having several matching arms will also
complain that something looks wrong?

However, that will require all the arms to be evaluated every time,
even after a match is found, which might not be the most optimal
approach.

Then again, if not all arms might be evaluated, the order of
evaluation is important (since several matching arms could be found),
but it's not stated in the RFC if the order of evaluating arms follows
the order they are written, or if the compiler/interpreter is allowed
to choose another order if it thinks it might find the matching arm
sooner?

---

To recap, perhaps you can answer these questions clearly in the RFC:
- What happens if more than one arm is matching?
- In which order are the arms evaluated (in case order is significant)
- is it predictable or an implementation detail that the developer
should not rely on?
- Can the left side of the arms be any expression or only
"constant-style"? (If expressions are allowed, order also becomes
significant)

Apart from these questions, it might be a good idea to evaluate the
impact of the Backwards Incompatible Changes by checking top
repositories for the use of the new keyword "match" in classes and
namespaces etc.

Finally, I find the mixing of match as expression and match as
stand-alone statement unfortunate. I understand very well the
closeness between the two, but I also think that those are two quite
different use-cases which presume different intentions and
expectations for behavior:

For example, when using "match" as an expression and assigning the
value to a variable (the second example at the top of the RFC - as an
alternative to hash maps and nested ternary operators) it's natural to
assume that one and exactly one arm must match. Otherwise the variable
will end up with an ambiguous or undefined value.
I also would consider it "flippant" and not a common need to use block
statements as the arms in this case!

On the contrary, when using "match" as a statement (much more like
"switch" and like "if"), there is no problem if no arms match, and if
several arms match, why not execute all of them? Also, block
statements in the arms would be natural and common.

Would it be a possibility to separate the two into different RFC's?
Personally I find the expression style most useful and I'd be happy to
see this part passed, which I think would be relatively easy since a
lot of the more complex points could be evaded: Block statements,
return statements, break/continue statements (which I don't really
understand in the context of an expression) and the trailing semicolon
issue.

Hope the feedback was useful and best of luck with the RFC!

Jakob