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=={}` or `match~{}` 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
