On 2018-03-30T15:10:32 -0400
Brian Goetz <brian.go...@oracle.com> wrote:
> Yes, you misunderstood :)
>
> You would always get an exhaustiveness check. What you'd not get is the
> "grace" of having said:
>
> case RED:
> case YELLOW:
> case GREEN:
>
> without a default, and having that still be considered exhaustive
> because these are all the alternatives known at compile time. It would
> be like today, where flow analysis sometimes requires you to have a
> default on an enum switch even though you've covered all the bases.
There's a subtlety to the language here that I think might be throwing
me off.
It's not clear to me what the utility of nominally always having an
exhaustiveness check would be if I end up having to include a "default"
everywhere anyway. If someone adds an enum constant (and I'm compiling
my code against their new code), I want to get compilation errors in
every switch that now needs to be updated. If I have to add a "default"
everywhere in the source, I won't get that (and will have to hope that
my test coverage is good enough to find all the switches that are now
incorrect).
My understanding to date has been that a "default" wasn't going to be
required for enum and sealed types, and that if I didn't provide one,
the compiler would synthesize one that raises an exception... Now
things seem to have shifted somewhat.
I configure my IDE to refuse to allow me to use default on enum
switches, and to treat missing cases as a compilation error:
switch (e) {
case RED: ...
case YELLOW: ...
case GREEN: ...
}
throw new UnreachableCodeException();
I don't specify a default, so the code raises UnreachableCodeException
if someone makes a binary-incompatible change and I've not recompiled,
and the IDE/compiler tells me if someone added an enum constant that
I've not handled by refusing to compile my code.
--
Mark Raynsford | http://www.io7m.com
