Allow dropping (true) from match expression conditions in 8.1

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