Re: Compile-time type hierarchy information in pattern switch

[Brian Goetz]

The intended implementation strategy is to lower complex switches to 
densely-numbered `int` switches, and then invoke a classifier function 
that takes a target and returns the int corresponding to the lowered 
case number.  The classifier function will be an `invokedynamic`, whose 
static bootstrap will contain a summary of the patterns.  (We've already 
done this for switches on strings, enums, longs, non-dense ints, etc.)


To deliver an early error, that means that (a) the compiler must encode 
through the static argument list all the assumptions it needs verified 
at runtime (e.g., `String <: Object`), and (b) at linkage time (the 
first time the switch is executed), those have to be tested.


Doing so is plenty easy, but there's a startup cost, which could be as 
bad as _O(n^2)_, if I have to validate that no two case labels are 
ordered inconsistently with subtyping.


A possible mitigation is to do the check as a system assertion, which 
only gets run if we are run with `-esa`; we then might still have some 
static code bloat (depending on how we encode the assumptions), but at 
least skip the dynamic check most of the time.


On 4/4/2018 1:01 PM, Mark Raynsford wrote:

I'm still giving thought to everything you've written, but I am
wondering: How feasible is it to get the above to fail early with an
informative exception/Error?

Re: Compile-time type hierarchy information in pattern switch

[Mark Raynsford]

On 2018-04-03T12:36:43 -0400
Brian Goetz  wrote:
>
> Here's one that I suspect we're not expecting to recover terribly well 
> from: hierarchy inversion.  Suppose at compile time A <: B.  So the 
> following is a sensible switch body:
> 
>  case String: println("String"); break;
>  case Object: println("Object"); break;
> 
> Now, imagine that by runtime, String no longer extends Object, but 
> instead Object absurdly extends String.  Do we still expect the above to 
> print String for all Strings, and Object for everything else?  Or is the 
> latter arm now dead at runtime, even though it wouldn't compile after 
> the change?  Or is this now UB, because it would no longer compile?

I'm still giving thought to everything you've written, but I am
wondering: How feasible is it to get the above to fail early with an
informative exception/Error?

-- 
Mark Raynsford | http://www.io7m.com