Hi! > 1. It uses the same AST, code generation and opcodes as the switch, I > don't agree that it is significantly different than the switch that we > already have.
This is reasoning in wrong direction. Nobody cares which opcode it uses. It is significantly different *for the user*, the fact that it may compile into same opcode means nothing to the user. > 2. Adding the `match` keyword is a breaking change, not an insignificant one. I thought with AST we should be past banning keywords as function etc. names, aren't we? > 3. If we can fix the switch statement semantics in the future the two > will only differ in that one returns a value and the other one > doesn't. This is a much smaller distinction than functions/closure. We don't need to "fix" anything in the existing switch, and likely couldn't because of immense BC breakage it would cause. If you want different switch, you better start with different keyword. > 4. If we'd every want to add pattern matching, we'd still have a > keyword available to us. What you proposing essentially *is* pattern matching, just very limited one. Extending it would be a natural development. > type coercion. This would make it a replacement of the switch > statement instead of an addition. I don't think we need replacement for switch statement. Adding simple matching expression seems to be a good idea, but please don't let it get out of the way and turn into something that is too complex and controversial and be buried under details that nobody actually needs. It's better to have sometime simple. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
