Everything

php

Putting the match expression in constant expressions in PHP 8.0 or 8.1

php.internals

tyson andre

6 years ago

Hi internals,

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.

For example, these two class constants would have equivalent behaviors if match expressions were allowed in constant expressions.

```
class MyClass {
    const CONFIG_SETTING = (APP_ENVIRONMENT == 'dev' || APP_ENVIRONMENT == 'stage') ? 'development-config' :
        (APP_ENVIRONMENT == 'prod' ? 'production-config' : null);

    const CONFIG_SETTING = match(APP_ENVIRONMENT) {
        'dev', 'stage' => 'development-config',
        'prod' => 'production-config',
        default => null,
    };
}
```

https://github.com/php/php-src/pull/5951 implements the main part of the change.

This is mostly for the sake of consistency, since match can be thought of as yet another control flow primitive that is more readable under some circumstances.

So I had some questions:
1. Should this target 8.0 or 8.1? I'm leaning towards 8.1 since the beta is already out.
2. Are there objections to doing this?
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)

Thanks,
- Tyson

Gabriel Caruso

6 years ago

On Sat, 8 Aug 2020 at 02:22, tyson andre <tysonandre775@hotmail.com> wrote:

> Hi internals,
>
> 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.
>
> For example, these two class constants would have equivalent behaviors if
> match expressions were allowed in constant expressions.
>
> ```
> class MyClass {
>     const CONFIG_SETTING = (APP_ENVIRONMENT == 'dev' || APP_ENVIRONMENT ==
> 'stage') ? 'development-config' :
>         (APP_ENVIRONMENT == 'prod' ? 'production-config' : null);
>
>     const CONFIG_SETTING = match(APP_ENVIRONMENT) {
>         'dev', 'stage' => 'development-config',
>         'prod' => 'production-config',
>         default => null,
>     };
> }
> ```
>
> https://github.com/php/php-src/pull/5951 implements the main part of the
> change.
>
> This is mostly for the sake of consistency, since match can be thought of
> as yet another control flow primitive that is more readable under some
> circumstances.
>
> So I had some questions:
> 1. Should this target 8.0 or 8.1? I'm leaning towards 8.1 since the beta
> is already out.
>

8.1, as PHP 8.0 is already FF and I'd consider your proposal a feature,
we'd need an RFC and everything else :)

Sara Golemon

6 years ago

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

tyson andre

6 years ago

Hi internals,

For unrelated reasons detailed in https://github.com/php/php-src/pull/5951#issuecomment-670969676 ,
I'm not planning on continuing work on this due to issues I found thinking about the proposal.
I initially started work on this because the intended behavior seemed underspecified.

"[No objections] from me, though I don't think I'd use it personally." sums up my current stance on that.

> Such a construct would be compile-time evaluated, so not having a match should result in a compile error.

Constants in PHP are lazily evaluated under some circumstances, e.g. class constants in constant expressions defer evaluation if they refer to other class constants so that classes aren't unnecessarily autoloaded.
https://github.com/php/php-src/pull/5951/files#diff-96ef697f12a482e3f2a7cb0966a6c5beR46 is an example of UnhandledMatchError in function default params, which are also deliberately not permanently cached by C.

Compile-time evaluation was something left out of that implementation, but is something that would get added in `zend_const_expr_to_zval`, like it already is for AST_CONDITIONAL.

- Tyson

Guilliam Xavier

6 years ago

On Sat, Aug 8, 2020 at 2:22 AM tyson andre <tysonandre775@hotmail.com>
wrote:

> Hi internals,
>
> 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.
>
> For example, these two class constants would have equivalent behaviors if
> match expressions were allowed in constant expressions.
>
> ```
> class MyClass {
>     const CONFIG_SETTING = (APP_ENVIRONMENT == 'dev' || APP_ENVIRONMENT ==
> 'stage') ? 'development-config' :
>         (APP_ENVIRONMENT == 'prod' ? 'production-config' : null);
>
>     const CONFIG_SETTING = match(APP_ENVIRONMENT) {
>         'dev', 'stage' => 'development-config',
>         'prod' => 'production-config',
>         default => null,
>     };
> }
> ```
>
> https://github.com/php/php-src/pull/5951 implements the main part of the
> change.
>

Hi, thanks, just noticed that your examples should use `===` not `==`.
Regards

--
Guilliam Xavier