Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109850
MIME-Version: 1.0
References: <CAPyj-LDo0AafB9FZoxUHU35Y7PAU+DYb4qGm+KV2-eF5KvNmng@mail.gmail.com>
In-Reply-To: <CAPyj-LDo0AafB9FZoxUHU35Y7PAU+DYb4qGm+KV2-eF5KvNmng@mail.gmail.com>
Date: Sun, 26 Apr 2020 10:15:11 +0200
Message-ID: <CADyq6sJHt6MFrh5rj5ZDtYFzZF2k-YKd43ukffBb4MxBrt9qLw@mail.gmail.com>
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002f863905a42d336d"
Subject: Re: [PHP-DEV] [VOTE] match expression
From: ocramius@gmail.com (Marco Pivetta)

--0000000000002f863905a42d336d
Content-Type: text/plain; charset="UTF-8"

Heya,

Just following up here, after private convo on why I voted "NO" on this RFC.

My rationale for not wanting the RFC (in its current state) is that I don't
want more procedural constructs in the language.

Specifically, I'm fine with:

match (<expression-to-be-matched>) {
    <potentially-matching-expression> =>
<result-expression-to-be-evaluated>,
    <potentially-matching-expression> =>
<result-expression-to-be-evaluated>,
    <potentially-matching-expression> =>
<result-expression-to-be-evaluated>,
    default => <result-expression-to-be-evaluated>,
}

I'm not fine with allowing procedural code to be executed on the
right-hand-side of each match.

It would still possible to hide procedural code in the right-hand-side of
the match, but luckily without affecting the outer scope:

match (<expression-to-be-matched>) {
    <potentially-matching-expression> => (function () { /* insert your
procedural nightmare of choice here */ })(),
    <potentially-matching-expression> => (fn () => /* more procedural
nightmares here */)(),
    default => <result-expression>,
}

By enforcing only expressions to be on the right-hand-side, we get some
nice side-effects too:

 * no need to discuss `continue`
 * no need to discuss `break`
 * no need to discuss `return`

Overall, that would be a win-win.

A point has been risen about the fact that using closures increases memory
usage and stack frames: that's a compiler optimization concern, and
probably also a minor one, since I'd discourage procedural code on the RHS
anyway :-)

I'd be voting YES on the RFC if the blocks were gone.

On Sat, Apr 25, 2020 at 12:40 PM Ilija Tovilo <tovilo.ilija@gmail.com>
wrote:

> Hi internals
>
> I have opened the voting on the match expression RFC. It will end on
> 9th of May, 2020.
> https://wiki.php.net/rfc/match_expression
>
> Here are the last changes:
>
> In the last update I mentioned allowing return values in blocks.
> Unfortunately, we discovered some technical difficulties (memory
> leaks) which are very hard to solve. Nikita is experimenting on a
> possible solution. There was also a fair bit of backlash over the
> syntax. Thus I have decided to move block expressions to a separate
> RFC. Note that blocks with just statements remain part of this RFC.
>
> The "duplicate condition" warning mentioned by Dan was removed due to
> the arguments made by Tyson.
>
> I have also moved the optional semicolon for the match in statement
> form to a separate vote as this was another controversial part of the
> proposal.
>
> Furthermore I have added another secondary vote for allowing to drop
> (true) conditions as that was suggested multiple times:
>
> match {
>     $age >= 30 => {},
>     $age >= 20 => {},
>     $age >= 10 => {},
>     default => {},
> }
>
> // Equivalent to
>
> match (true) {
>     $age >= 30 => {},
>     $age >= 20 => {},
>     $age >= 10 => {},
>     default => {},
> }
>
> There is a separate poll for specifying the reason for a "no" vote.
> Let me know if there are any other reasons so I can add those to the
> poll.
>
> A personal thank you goes out to Tyson for his guidance!
>
> Regards,
> Ilija
>

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--0000000000002f863905a42d336d--