Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110267
MIME-Version: 1.0
References: <CAPyj-LB7jSiv+7DheaYpEcZXbjeJ9OMsRUTMOofnWbH4LyOQhA@mail.gmail.com>
In-Reply-To: <CAPyj-LB7jSiv+7DheaYpEcZXbjeJ9OMsRUTMOofnWbH4LyOQhA@mail.gmail.com>
Date: Sat, 23 May 2020 00:30:50 -0700
Message-ID: <CANaX5negML1uV=GtSc7zkkHPBfbpb6xa721USW31+_-4X-onfQ@mail.gmail.com>
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003beaf005a64bba5e"
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Match expression v2
From: davey@php.net (Davey Shafik)

--0000000000003beaf005a64bba5e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 22, 2020 at 4:09 AM Ilija Tovilo <tovilo.ilija@gmail.com> 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
>

With these simplifications, I'm not entirely sure there is enough value
here if the Conditional Return, Break, and Continue Statements RFC is
passed. This could be written with the slightly more ugly, but serviceable:

So this:
$statement =3D match ($this->lexer->lookahead['type']) {
    Lexer::T_SELECT =3D> $this->SelectStatement(),
    Lexer::T_UPDATE =3D> $this->UpdateStatement(),
    Lexer::T_DELETE =3D> $this->DeleteStatement(),
    default =3D> $this->syntaxError('SELECT, UPDATE or DELETE'),
};

could be expressed as:

echo (function($match) {
    return $this->SelectStatement() if ($match =3D=3D=3D Lexer::T_SELECT);
    return $this->UpdateStatement() if ($match =3D=3D=3D Lexer::T_UPDATE);
    return $this->DeleteStatement() if ($match =3D=3D=3D Lexer::T_DELETE);
    return $this->syntaxError('SELECT, UPDATE or DELETE');
})($this->lexer->lookahead['type']);

I mean, ultimately, it's equivalent to:

echo (function($match) {
    if ($match =3D=3D=3D Lexer::T_SELECT) {
        return $this->SelectStatement()
    }
    if ($match =3D=3D=3D Lexer::T_UPDATE) {
        return $this->UpdateStatement()
    }
    if ($match =3D=3D=3D Lexer::T_DELETE) {
        return $this->SelectStatement()
    }
    return $this->syntaxError('SELECT, UPDATE or DELETE');
})($this->lexer->lookahead['type']);

The main selling point for match is that it's more concise, I'm not
convinced that the return if variant is much less concise. If you want to
match more than one thing, use the OR (double pipe) operator in the if
condition.

Having said that=E2=80=A6 match is undeniably prettier. If we are doing thi=
s
however, I'd prefer to implement Go's switch block, named match because we
already have a switch. It's strict, but flexible.

- Davey

--0000000000003beaf005a64bba5e--