moving to spec-experts as it can interest others.
Hi Stephen,
First, thanks to do a detailed analysis of the rational of your proposal.
I think i agree with you about the fact that the expression switch does need to
support fallthrough,
more on that in a folowing email.
I also agree with you th
Do we need fallthrough in an expression switch, i believe like Stephen that we
don't.
First, as Stephen point in it's example, if we have comma separated cases, we
need less fallthrough and even if we have a code like this
var value = switch(x) {
case 0:
foo();
case 1:
bar
I agree, i do not think it's a good idea to introduce record as annotation
value just because we can but that's not the reason why i think we should
introduce record as annotation value.
There is a lot of time where you can construct an annotation with invalid
values but those invalid annota
I'm skeptical of this feature, because (a) its not as widely applicable
as it looks, (b) its error-prone.
Both of these stem from the fact that comparing classes with == excludes
subtypes. So it really only works with final classes -- but if we had a
feature like this, people might mistakenly
I think i agree with you about the fact that the expression switch does need to
support fallthrough,
more on that in a folowing email.
I've been leaving this topic until we have ironed out the higher-order
bits, but this seems a good enough time to start this discussion.
I also agree with
There's been some active discussion on "Is this the switch expression
construct we're looking for" over on amber-dev. Its a good time to take
stock of where we are, and identifying any loose ends.
## Approach
Our approach is driven not merely by the desire to have an expression
form of switc
Hello!
Does not sound convincing. First, to my experience, it's quite widely
applicable. My first two samples were from what you called a low-level
libraries just because I wanted to grep something well-known. Now I grepped
jdk10 source by `\w+ == \w+\.class` and scanned manually about 10% of the
