On Mon, Apr 13, 2020, at 10:08 AM, David Rodrigues wrote: > With all the humility of the world and without wanting to be exhaustive > about this, my only question is why can't we keep it as a switch, instead > of creating a new keyword?
That was the original proposal. The main issue came down to it being too much different functionality crammed into one bit of syntax, where lots of subtle little context would change the meaning and what you had to do. That's difficult for users, and for the parser. Fundamentally, this is not a switch statement. I think it is an error to equate it to or relate it to a switch statement. It's a more powerful, multi-branch version of the ternary operator, and should be conceptualized as such. And conceptualized that way, I really want it. :-) Piggybacking off of if makes slightly more sense than off of switch, but it then involves a lot more syntax and a lot more typing, plus the confusion about when it needs a semi-colon and when it doesn't. A new keyword creates a mental separation that is beneficial to users, and allows it to be implemented with a minimum of syntax and no conditional syntax (where certain sigils are needed only in some situations and are an error in others). > Em seg., 13 de abr. de 2020 às 11:49, Rowan Tommins <rowan.coll...@gmail.com> > escreveu: > > > On 13/04/2020 12:28, Ilija Tovilo wrote: > > >> It would be possible for the blocks to return values (though not with > > >> the return keyword). > > >> [...] > > > We can't do everything at once. > > > > Then why not introduce the match expression first, and add block > > expressions (as a general concept) later? That way, we don't need all > > the special restrictions on when to use them, and can work out a > > consistent set of rules for them which can apply language-wide, rather > > than being constrained later by decisions we make half-implementing them > > now. > > > > The ability to use them with short closure syntax would be very > > interesting, if the scoping/capture rules could be agreed. I really feel like this is the best solution. Multi-line expressions are not a logical one-off part of match(). They may or may not be a good idea for PHP generally, in which case they should be proposed and thought through generally. If they do end up being a good move generally, they'll apply to match naturally just like everywhere else; if not, then they wouldn't confuse people by being a one-off part of match() and nowhere else. The various discussion about parse logic when the semicolon is there or not only highlights that it is not a fully-developed concept. There's a lot more thought and design that needs to go into multi-line expressions that is not in scope for a match expression; embedding statements inside an expression is just weird... Please, pull that part out. It's the most (only?) controversial part right now. I suspect (note: no data) that the RFC would pass almost unanimously without it (which is good; I want this RFC to pass). With it, it may pass or not, but it would be a weaker proposal. At the very least bump it to an secondary add-on vote. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
