Hi internals,
https://wiki.php.net/rfc/match_expression_v2#allow_dropping_true
mentioned this in the future scope.
$result = match { ... };
// Equivalent to
$result = match (true) { ... };
https://externals.io/message/110243#110292 summarizes the current status
80% were in favor of this feature but it's also worth noting that only
20 people have voted. To avoid risking another rejection and thus the
RFC being delayed for a year I'd rather move the feature to a
different RFC. Also, the feature being included in the first draft was
a rash decision in the first place (completely my fault). There are
multiple ways to deal with the value comparison (e.g. do type coercion
like the switch or type-error on a non-boolean value) but they haven't
been discussed at all.
I'm not the RFC author, but discussing alternatives was brought up 2 months ago.
I'm in favor of strict equality, but would be fine with loose equality.
Personally, I feel like adding a type error on a non-boolean value would be inconsistent
with the short-circuiting behavior I'd expect from match.
Additionally, if the first conditions are almost always true,
this would make bugs in the last conditions harder to find.
People might intuitively expect match { and match(true) { to do the same thing
when refactoring code, and be surprised if loose comparison cast behavior introduces bugs after a refactoring
(e.g. match { $arrayOrBool => ..., default => process_array_or_false() })
- Maybe adding a loose comparison equivalent for
match=={}ormatch~{}or something (both with and without an expression) would help.
I can see use cases for it but I'm not sure what others think or if it'd be worth the language complexity (e.g. already possible to cast arm conditions to booleans)
(e.g. dealing with user input that may be an int or stringified int from db/user input/a remote API call)
Thanks,
- Tyson