Everything

php

[DECLINED] match expression RFC

php.internals

Ilija Tovilo

6 years ago

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

Jakob Givoni

6 years ago

On Sat, May 9, 2020 at 6:08 PM Ilija Tovilo <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

Ilija Tovilo

6 years ago

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

Kalle Sommer Nielsen

6 years ago

Hi

Den søn. 17. maj 2020 kl. 23.01 skrev Ilija Tovilo <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

Ilija Tovilo

6 years ago

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