Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109613
To: internals@lists.php.net
References: <CAPyj-LDfdATXFD+dc5AY9EqWWxgf8LP1joD2fzvm==1gUoN35A@mail.gmail.com>
Date: Tue, 14 Apr 2020 01:39:22 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0)
 Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2
MIME-Version: 1.0
In-Reply-To: <CAPyj-LDfdATXFD+dc5AY9EqWWxgf8LP1joD2fzvm==1gUoN35A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [DISCUSSION] Match expression
From: ajf@ajf.me (Andrea Faulds)
Message-ID: <php.internals-109613@news.php.net>

Hi Ilja,

Ilija Tovilo 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

I like this proposal in general, I've wanted something like Haskell and 
Rust's case/match statements for years but never got round to proposing 
them. I do have some comments and concerns however:

* While I like the Rust-like feature of being able to use it both as a
   statement and as an expression, I share others' concern that it is
   inconsistent with PHP's existing statements. I would suggest either
   an RFC to apply this to other statements, or to take it out for now.

* It is a shame you don't suggest taking this opportunity to add pattern
   matching. We already have destructuring assignment syntax in PHP,
   albeit only for arrays, so why not support pattern-matching for arrays
   in `match` right now? I guess variable scope might be awkward (matched
   values would leak into function scope), but it is for other statements
   already. If we do not add pattern matching right now, perhaps we can
   design the syntax so it doesn't prevent adding it later? Using a
   keyword prefix (e.g. `let`) in future means we end up with two kinds
   of arm (one with === behaviour, one with pattern-matching behaviour),
   but wouldn't it be simpler to have just one?

* Relatedly, it is a shame not to have guards. `switch (true)` is not a
   very nice idiom, `match (true)` is worse (no handling of truthiness),
   and neither provides the full power that patterns + guards together
   provide, where you can neatly combine pure value matching with
   arbitrary boolean checks. Sure, you can write `($foo === BAR) =>`,
   but you might as well use an if-statement then. I shouldn't let
   perfect be the enemy of the good, but I think there's so much more
   that could be done here. Note that even the limited possible patterns
   without inventing new syntax (a plain variable, and an array pattern)
   are more useful if guards are available.

* It is unfortunate if we have to add another reserved word… I don't
   know if there'd be a way to do this with `switch` that isn't
   confusable with the existing statement, though.

Thanks,
Andrea