[DECLINED] match expression RFC

  110098
May 9, 2020 16:07 tovilo.ilija@gmail.com (Ilija Tovilo)
Hi internals

I closed the vote on the match expression RFC.
https://wiki.php.net/rfc/match_expression

First of all, thank you to everybody who participated!

It was declined with 28 no and 6 yes votes. There were three main criticisms:

1. The RFC wasn't discussed extensively enough and too many changes
were made last minute
2. match should be expression only (no blocks)
3. Omitting (true) should loosely compare the arm condition to true

Criticism 1 is absolutely justified and 3 makes sense to me.

Unfortunately, I think criticism 2 somewhat defeats the purpose of the
RFC (at least how I envisioned it). The main motivation to me was a
new switch statement with safer semantics. Returning values was a nice
secondary feature. According to Nikitas analysis (1) an expression
only match would be usable in roughly 40% of cases where a switch
would've previously been used. Failing to address the other 60% seems
less than ideal, especially given the fact that the plan is to extend
match with pattern matching.

If we do decide to remove blocks I think the RFC needs to find a
different motivation since criticizing switch without offering an
alternative seems disingenuous. I will take the next few days to think
about how to move forward.

Thanks again!

Ilija

1) https://externals.io/message/109842#109868
  110198
May 17, 2020 15:35 jakob@givoni.dk (Jakob Givoni)
On Sat, May 9, 2020 at 6:08 PM Ilija Tovilo ilija@gmail.com> wrote:
> > I will take the next few days to think > about how to move forward. >
Hi Ilija, Have you thought about what you'll do next? I think the part about introducing "match" as an alternative to hashmaps and nested ternaries is a no-brainer - there seemed to be pretty good support for that. Regarding an actual alternative to the horrible "switch", maybe we can introduce it using "case/when" like in SQL? If you're sure you're not going to pursue one of these options, maybe let us know, so someone else can give it a go based on your excellent work and while it's still fresh :-) Best, Jakob
  110199
May 17, 2020 20:00 tovilo.ilija@gmail.com (Ilija Tovilo)
Hi Jakob

> If you're sure you're not going to pursue one of these options, maybe > let us know, so someone else can give it a go based on your excellent > work and while it's still fresh :-)
I'm working on a second draft with the following changes: 1. Blocks were removed 2. Secondary votes were removed 3. Proposal was simplified (roughly 60% was removed) 4. Discussion period will stay open for longer I will announce v2 of the RFC in a few days. I will also discuss blocks in a separate RFC (language wide blocks vs blocks restricted to specific cases) for PHP 8.1 once people have had the chance to use match for a few months. Ilija
  110200
May 17, 2020 20:07 kalle@php.net (Kalle Sommer Nielsen)
Hi

Den søn. 17. maj 2020 kl. 23.01 skrev Ilija Tovilo ilija@gmail..com>:
> > Hi Jakob > > > If you're sure you're not going to pursue one of these options, maybe > > let us know, so someone else can give it a go based on your excellent > > work and while it's still fresh :-) > > I'm working on a second draft with the following changes: > > 1. Blocks were removed > 2. Secondary votes were removed > 3. Proposal was simplified (roughly 60% was removed) > 4. Discussion period will stay open for longer > > I will announce v2 of the RFC in a few days.
Resurrecting rejected RFCs have a "cooldown" of 6 months: https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals Whether or not your new RFC qualifies for the second part of this is rule, I can't tell as its left vaguely defined and I can't recall it being used besides the scalar type hints RFCs. Perhaps someone smarter than me can phrase this better. -- regards, Kalle Sommer Nielsen kalle@php.net
  110201
May 17, 2020 20:30 tovilo.ilija@gmail.com (Ilija Tovilo)
Hi Kralle

> Whether or not your new RFC qualifies for the second part of this is > rule, I can't tell as its left vaguely defined and I can't recall it > being used besides the scalar type hints RFCs. Perhaps someone smarter > than me can phrase this better.
The docs say the following:
> The author(s) make substantial changes to the proposal. While it's impossible > to put clear definitions on what constitutes 'substantial' changes, they should > be material enough so that they'll significantly affect the outcome of another > vote.
The feedback was almost exclusively limited to two things (the new draft addresses both): * Blocks should be removed * The RFC wasn't discussed extensively enough My suggestion: I'll finish the draft and announce it in a few days. This will make it easier to judge if enough changes were made. If not I'll postpone the RFC for six months. Ilija