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 <[email protected]>
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/
