Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111377
MIME-Version: 1.0
References: <DM6PR07MB6618916B074C7C1467DB1A9BF9460@DM6PR07MB6618.namprd07.prod.outlook.com>
In-Reply-To: <DM6PR07MB6618916B074C7C1467DB1A9BF9460@DM6PR07MB6618.namprd07.prod.outlook.com>
Date: Sat, 8 Aug 2020 10:58:17 -0500
Message-ID: <CAESVnVq5i2wf03toDbc=7H1ndYCSry92QWQw4Ze4ApOPriUT2g@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d7f23005ac5fca3b"
Subject: Re: [PHP-DEV] Putting the match expression in constant expressions in
 PHP 8.0 or 8.1
From: pollita@php.net (Sara Golemon)

--000000000000d7f23005ac5fca3b
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 7, 2020 at 7:22 PM tyson andre <tysonandre775@hotmail.com>
wrote:

> The match expression can be thought of as a much more concise/readable
> equivalent to chained ternary operators.
> I'm proposing allowing matches in constant expressions when all parts of
> the match are constant expressions.
>
>
That seems pretty reasonable.


> 1. Should this target 8.0 or 8.1? I'm leaning towards 8.1 since the beta
> is already out.
>

8.1, the 8.0 ship has sailed.


> 2. Are there objections to doing this?
>

Not from me, though I don't think I'd use it personally.


> 3. Should/shouldn't php enforce that the default arm exists for match *in
> constant expressions*
>    (constant expressions can already throw errors when evaluated for
> various reasons, but UnhandledMatchError is new)
>

Such a construct would be compile-time evaluated, so not having a match
should result in a compile error.  Having a default should be considered
best-practice (to avoid surprise compile failures), but I don't think it
needs to be a hard-requirement.

-Sara

--000000000000d7f23005ac5fca3b--