Expression switch exception naming
Jeremy Barrow
jeremy.a.barrow at gmail.com
Mon May 14 20:31:31 UTC 2018
I'll just chime in here with regard to un/sealed enums and exhaustive
switches.
I think Kevin was on the right track when he pointed out the connection
between exhaustive switches and interfaces.
The thing I think was overlooked was the default method analogy.
Once you try translating that into an exhaustive switch context, it
seemingly makes no sense on the surface.
But we have annotations.
The author of the enum could annotate the enum as exhaustive/sealed, and it
would act like a completely sealed class.
Every possibility must be handled.
But, as has been pointed out, not all enums have the luxury of guaranteeing
they'll have nothing added.
So, introduce a second level.
Annotate a subset of the enum for the completeness check.
This covers non-invasive enum additions.
It gives you more leverage over the compiler, and the ability to tell it
which enums to check, and more specifically, which enum variants to ignore.
I don't know how that would play with a default case though.
Side-note: I also see a bit of overlap with this and a "please use this
return value" check.
You're telling the compiler, "hey, make sure the programmer deals with
this".
Which might make this more interesting if we go down the route of forcing
the caller to handle return values in the future.
More information about the amber-dev
mailing list