I love everything about this, except for one deal killer.
I love the use of =>. And I love the blocks.
Plus I love that it can fully replace switch because of how using switch can
easily allow an developer's oversight to introduce subtle bugs.
The deal killer IMO is this:
"match was added as a keyword (reserved_non_modifiers). This means it can't be
used in the following contexts anymore:
• namespaces
• class names
• function names
• global constants"
-Mike
> On Apr 11, 2020, at 8:16 PM, Ilija Tovilo <[email protected]> wrote:
>
> Hi internals
>
> 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
>
> Due to the feedback I decided to take the RFC in a slightly different
> direction. The main objections were:
>
> 1. It didn't behave like the traditional switch so it shouldn't use
> the switch keyword
> 2. It didn't fix type coercion
> 3. The RFC was poorly structured
>
> In hindsight I understand why I had a hard time writing the RFC. I
> tried making a case against the switch statement while really not
> addressing the switch statement at all. The new RFC proposes a match
> expression that fixes all the objections raised against the switch
> statement. Additionally, match arms can now contain statement lists
> which allows you to use the match expression anywhere the switch
> statement would have been used previously.
>
> While some people have suggested statement lists aren't necessary I
> don't think it makes sense to raise objections against the switch
> statement without offering an alternative.
>
> I also experimented with pattern matching but decided against it. The
> exact reason is described in the RFC.
>
> I'm now confident this is the right approach. I hope you will be
> happier with this proposal.
>
> Happy Easter!
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
