On 31 March 2020 19:50:59 BST, Ilija Tovilo <tovilo.il...@gmail.com> wrote: >There's been a fundamental disagreement on what the switch expression >should actually be. Due to the conflicting feedback I no longer know >how to proceed.
I think this confusion is there in your proposal, not just in people's responses to it. In the new poll, you say this: > The question seems to be if this new construct > should be a variation of the switch to make it > usable as an expression (like the RFC currently > suggests) But the introduction of the actual RFC doesn't even mention the expression part, only that you want to solve some of the problems of the current statement: > The switch statement has some long-standing > issues that we're going to look at in this RFC. You then go onto describe 4 problems, and propose a new syntax that solves 3 of them, with only the type coercion part retaining the switch statement's behaviour. I don't think people are saying they *want* the proposal to be more of "an alternative to the switch statement that fixes all the issues mentioned in the RFC", they're saying that what you've currently proposed *is* that replacement. If that's the intention, using a new keyword would make sense. If the intention is to make this feel like an expression version of the switch statement, then making it look more similar would make sense. I think it's ultimately up to you which direction you want to take the proposal, but you should pick one and follow it through. Personally, I think changing the keyword to "match", and possibly using strict comparison, would make a compelling feature. I don't think this part would be needed or desirable: > Each case can contain a single expression, or a > block with a statement list if the expression > result is discarded I think it's perfectly fine to have a match expression that's built only from expressions. If someone wants flow control, they can use other features, the new syntax doesn't need to do everything. Regards, Hi Ilija, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
