Exhaustiveness in switch

[Kevin Bourrillion]

On Thu, May 10, 2018 at 1:54 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> * I think that for most occurrences of `default: throw...`, by far, the
> user really doesn't benefit from being able to choose the exception type or
> the message at all. A standardized choice of exception, and an
> autogenerated message (that automatically includes the switch target, which
> users usually don't bother to do themselves!), may be strictly better. Can
> we consider providing them a shortcut (strawman: just `default: throw;`!)?
>
>
> We did actually discuss this very notion.  While its attractive, it also
> feels like an attractor for an infinite stream of "can you let me customize
> x/y/z" requests.  So we wanted to explore whether there are library moves
> we can make that get us to this benefit first.  For example, if you could
> say
>
>     default: throw switchException();
>
> where switchExpression() was a static-import of
> Intrinsics.switchExpression() (which could still capture Object.toString()
> of the target, as well as a description of the switch context), that's a
> smaller hammer with more flexibility.
>

Yes, that sounds like it ticks the boxes as well. Could we apply this
strategy to all "I believe this line to be unreachable" situations?

* For exhaustive switches (so far: enums), the ideal we have been trying to
> shoot for is that the user makes an informed, intelligent choice about
> whether they want the compile error or the runtime error when a new one is
> added. So far, with what we've implemented at Google, it seems that we're
> falling fall short of that ideal. We have been strongly considering the
> idea that you *shouldn't* be allowed to simply omit a default at all,
> because what that *means* is far too opaque. It would be better if the
> user had to do something explicit in either case. Could it be that the idea
> in the previous bullet actually provides this? We would go back to always
> requiring an explicit `default` for an e-switch, but you still get to make
> an explicit choice which behavior you're asking for.
>
>
> That sounds like a turnaround.  Previously, you'd argued that specifying
> all the enum cases and omitting a default was ideal because then you have a
> valuable tripwire against new values being added without them getting swept
> under the rug.
>

The only distinction I am discussing now is whether it is implicit or
explicit.  It was never my intention to argue that the benefits came from
the implicitness - I just want there to be a way to choose between the two
behaviors.



-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180510/3e012f98/attachment-0001.html>