5 ms·
The “&&” one is bizarre, it makes it look like the whole thing is a Boolean expression, which it absolutely is not. That gets even weirder because the part righ
by anyfoo 4y ago
The “&&” one is bizarre, it makes it look like the whole thing is a Boolean expression, which it absolutely is not. That gets even weirder because the part right of it actually is a Boolean expression, so on top of very confusing reading you now make it look like there are strange interactions with operator precedence. Using && is one of the worst choices.
The “if” one does not suffer from any such problem and reads okay to me. I guess one argument against it could be that since the whole thing is a distinct grammatical construct, why not just introduce a distinct keyword instead of making an existing keyword depending on context? That’s mostly a question of style though (e.g. I don’t know right now if Java already has an habit of reusing keywords like that).
- mikepurvis 4y agoI'm not a Java user, but I really don't love the overloading of `if` in Python (statement, ternary, comprehensions), so introducing a new keyword here seems pretty reasonable to me. And don't even get me started on `static` in C++.
- pajko 4y agoOK, no static then, but what about if constexpr (...) ? :D
- planede 4y agoAlso `if consteval {...}` in C++23. But really "if" still semantically means the same thing in all of these. Unlike "static", which is all over the place.
- rerdavies 4y agoAnd then there's "static constexpr" (which is only used in places where non-static constexprs are illegal). An overloaded keyword that's become so overloaded, it's even used in places where it's completely unnecessary! :-P
- garblegarble 4y agoThe "&&" approach is how you express that same logic in an if statement in Java today. Given this pattern matching syntax change, you'd write: switch(obj) { case Tuner t when guitar.isInTune() -> ...; ... } For a switch, but for an if statement it's written as: if (obj instanceof Tuner t && guitar.isInTune()) { ... } Edit: I do wonder, actually, if avoiding "&&" is to allow the "when" case execution to be reordered (e.g. to allow JIT to extract common "when" conditions prior to the switch expression), which would be wrong to do given the short-circuiting rule implications of "&&"
- hn_throwaway_99 4y agoAs another comment mention, they did use && in the 2nd preview, but then switched it, so you're right, it must have been confusing. FWIW, though, I don't find it "bizarre". While it's not a boolean expression per Java, at least in my mind it serves the same purpose: "in the case that thing x is of type SomeType and ...some other thing about ((SomeType)x) is true...". I think it's a tough choice, I'm sure they were probably not wanting to add a new keyword, but at the end of the day "when" is so familiar to anyone who's ever written SQL (which I'm guessing is most Java devs) so seems like a good choice.
- anyfoo 4y ago> While it's not a boolean expression per Java, at least in my mind it serves the same purpose But if some construct looks the same, but is not the same, and worse, only "somewhat" the same, you get confusing behavior. At least for newcomers, or even just software engineers who just don't care about language grammar that deeply (which I imagine are not only a lot, but also a lot of the Java target audience specifically). Case in point, the author I was replying to wondered in a followup whether && would/should still act like a shortcut-and operator would, or not. There is definitely some subjectivity to it, but personally I much prefer if different constructs look clearly different. Any ambiguity is squashed immediately, and in the case of "when" it's still fully clear how it works. I'm also okay with the "if" variant, because while it reuses a keyword, it's clearly a different "if".
- pkulak 4y agoI think Rust uses "if" for its match guards too and I don't recall it upsetting anyone. I'm all for keeping things consistent between languages if only to prevent too much bike shedding.
- tialaramex 4y agoRust's if never needs parentheses, so their absence in a match guard is unremarkable, whereas in Java that's incongruous one way or the other.