Next up for patterns: type patterns in switch

[Brian Goetz]

> I haven't read all the discussions in this thread, so sorry if my
> points were already covered.

As it turned out, that’s probably best :)

> It looks like relocating the problem to defaults have a hole for this
> trivial switch:
>
> switch(obj) {
>  case null:  // fallthrough
>  default:
> }
>
> If we think that default case always throws for null, should this 
> switch throw?

Nice “catch”, fall through claims another victim.

To summarize some of the previous discussions: the original document 
kind of leaves “default” to rot, but perhaps it can be rehabilititated 
to have more of a role, such as indicating “this switch is total and 
this is the last case.”  I’m going to start another discussion on this.

> It's unclear for me how exhaustiveness on nested patterns plays with
> null. case Box(Circle c) and case Box(Rect r) don't cover case
> Box(null) which is a valid possibility for Box<Shape> type.

It’s not even clear how exhaustiveness plays with null even without 
nesting :)  Moved to a separate thread.

> I'm still heavily concerned about any patterns with the explicit type
> (`T t` on an operand of type `U`, where `U <: T`).

To be moved to a separate thread.