Variants/case classes/algebraic data types/sums/oh my!

[Brian Goetz]

>    Can a concrete value class extend another value type? No.
>      (Because concrete value classes are final.)
>    Can a value class be abstract or non-final? No.
>      (Abstract value classes do not presently seem worthwhile.)
>
> That seems like a fairly large conflict there...

Value types are /*representationally monomorphic*/ but can implement 
interfaces.  So in your example, if T and C are interfaces, you don't 
have a problem.

The motivation for this restriction is simple: this is what lets values 
"act like an int" -- pass them by value, flatten them into objects and 
arrays -- all without requiring object headers to be stapled on.

> It's not clear to me from the nestmates proposal if children of a
> NestTop can also be NestTops (I think this would be needed, or at least
> another level of indirection would be needed to use the nestmates data
> directly for implementing matching as shown above).

A class belongs to exactly one nest; nests form a partition of classes, 
and therefore enjoy all the nice mathematical properties of partitions 
(e.g., arbitrary choice of canonical member, etc.)

A nest is a means of saying "this group of classes derive from a common 
accessibility domain."  This supports both inner classes (multiple 
classes defined in a source file can be considered to trust each other) 
and parameterized classes (List<int> and List<long> can be considered to 
trust each other.) Nests are not intended to be a general "friend" 
mechanism; they merely capture (a generalization of) the "derived from a 
common source unit" notion.

>
> It does sound quite wonderful. This actually came up in conversation
> with someone recently, but do you think that lambdas will benefit from
> this work? It seems that with the combination of escape analysis and
> value types, you could stack allocate closures.

Yes, this is an obvious goal.  We were careful to define the semantics 
of lambda capture to disavow any assumptions of identity, which would 
allow us to (eventually) represent lambdas as values, including lambdas 
with captures.  The cost difference between stateless and capturing 
lambdas is entirely an accident of representation, and with a better 
representation, this can be improved.

That said, the hard part of getting here is not the VM mechanics, but 
how it fits into the type system, and maintaining compatibility with how 
things work now.