Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110249
User-Agent: Cyrus-JMAP/3.3.0-dev0-488-g9249dd4-fm-20200522.001-g9249dd48
Mime-Version: 1.0
Message-ID: <41139a8e-7e32-484c-826b-de407d5eca4b@www.fastmail.com>
In-Reply-To: 
 <CAPyj-LB7jSiv+7DheaYpEcZXbjeJ9OMsRUTMOofnWbH4LyOQhA@mail.gmail.com>
References: 
 <CAPyj-LB7jSiv+7DheaYpEcZXbjeJ9OMsRUTMOofnWbH4LyOQhA@mail.gmail.com>
Date: Fri, 22 May 2020 10:30:10 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Match expression v2
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, May 22, 2020, at 6:08 AM, Ilija Tovilo wrote:
> Hi internals
> 
> I'd like to announce the match expression v2 RFC:
> https://wiki.php.net/rfc/match_expression_v2
> 
> The goal of the new draft is to be as simple and uncontroversial as
> possible. It differs from v1 in the following ways:
> 
> * Blocks were removed
> * Secondary votes were removed
>     * optional semicolon
>     * omitting `(true)`
> * Unimportant details were removed (e.g. examples for future scope)
> 
> You can look at the diff here:
> https://github.com/iluuu1994/match-expression-rfc/pull/8/files
> 
> I will also leave the discussion period open for longer as that too
> was one of the primary criticisms.
> 
> As mentioned by Kalle:
> 
> > Resurrecting rejected RFCs have a "cooldown" of 6 months:
> > https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals
> 
> That is, unless:
> 
> > 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.
> 
> Given that many people have said without blocks they'd vote yes I'd
> say this is the case here. Let me know if you don't agree.
> 
> Ilija

I'd say this is a textbook example of sufficiently "substantial."

Thanks, Ilija!  This looks a lot better.

My one question is why you're not including the implicit "match (true)" in this version, when the secondary vote on the previous RFC was 80% in favor of it.

(And I still think the argument is stronger if you include a comparison to ternary assignment, but that doesn't affect implementation.)

--Larry Garfield