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:
- Should this target 8.0 or 8.1? I'm leaning towards 8.1 since the beta is already out.
- Are there objections to doing this?
- 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
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:
- 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 :)
- Are there objections to doing this?
- 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
--To unsubscribe, visit: https://www.php.net/unsub.php
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.
- 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.
- Are there objections to doing this?
Not from me, though I don't think I'd use it personally.
- 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
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
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