-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Proposal: Make match expression a constant expression (when parts are constant) #5951
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
I'd forgotten to check if this was part of the original RFC. It seems like constant expressions using match can be thought of as a much more concise form than chained ternary operators. It's already possible for constant expressions to throw, e.g. - Undeclared constants. - Wrong operands for unary or binary operators.
I don't really see a usefulness for match in constant expression context, but I'd be okay with allowing it for the sake of consistency. You should probably start an internals thread about this, to decide which version to target. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not, could be useful in some cases (although probably rare) 🙂
Zend/tests/match/044.phpt
Outdated
--FILE-- | ||
<?php | ||
|
||
// Here, this test uses strtolower because the locale dependence and change to the string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Incorrect comment :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, got sidetracked checking if constant expressions were proposed before and forgot to update this.
On second thought, I don't think I'll use this often enough to justify working on this. Both of the alternatives aren't perfect, but I'd probably still vote yes on either of them if someone else started the RFC process for them (e.g. based on this code)
|
@@ -654,6 +654,51 @@ ZEND_API int ZEND_FASTCALL zend_ast_evaluate(zval *result, zend_ast *ast, zend_c | |||
zval_ptr_dtor_nogc(&op1); | |||
} | |||
break; | |||
case ZEND_AST_MATCH: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
zend_const_expr_to_zval
would also benefit from being updated to support ZEND_AST_MATCH, but it'd only matter if this were to be supported in constant expressions
Motivations: This would be potentially useful for class constant and static variable declarations that would previously need to use
(some_value === b ? c : (some_value === d || some_value === d2 ? e : f))
instead ofmatch (some_value) { b => c, d, d2 => e, default => f}
I'd forgotten to check if this was part of the original RFC earlier.
It seems like constant expressions using match can be thought of as a much
more concise form of conditional than chained ternary(a?b:c) operators.
It's already possible for constant expressions to throw, e.g.
(But the UnhandledMatchError would be new,)
@nikic @iluuu1994 - thoughts on allowing this for PHP 8.0 or 8.1? I'd personally assumed this would be an implementation oversight since I don't remember seeing constant expressions discussed (it was a large PR)
Prior to this proposed change, the error message was always
Constant expression contains invalid operations