My thinking on this topic has evolved a bit. At first, we thought about
conditional methods as being completely ad-hoc, such as:
interface List<T> {
<where T=int>
long sum();
}
Here, the sum() method exists as an island in various specializations.
This was practical in the first iteration of the template classfile
mechanism (the "standing on segments" one), but adds a lot of
complexity. Our current thinking is that conditionality comes from
constraint. That is, the rules about overloads are performed without
respect to conditionality, and then the conditionality constraints
restrict the members of a particular specialization. So the
int-sums-to-long example is out, and instead we'd end up with the more
parametric
<where T extends Arithmable<T>>
T sum();
We likely need a better way of describing constraints. The obvious
kinds of constraints are `T=int` and `T <: Comparable<T>`, but these
don't go far enough, nor are they likely to be flexible enough. The
general way to describe a predicate on types is type classes. And "has
identity" or "has no identity" are easily described by a built-in type
class, without having to pollute the hierarchy.
The key here for purposes of specialization is that we be able to
con(dy)jure a constant witness to the type class at the point of
describing the specialized List, so that witness-provided behavior can
be folded into the specialized implementation.
During our various discussions, we've also used `IdentityObject` and
`ValueObject` as constraints in the t-vars / parametric VM proposal to
address methods that are only partially applicable. We've also talked
about using that as a signal to allow locking and other
identity-operations to compile inside generic code that we can
statically know won't have to deal with values.
Does giving up on having VO/IO in the type system change our
approaches to either the parametric vm future or identity operations
in generic code? It sounds like we're willing to give up on the
second but I don't have a good sense of what this does to the
parametric VM.
--Dan
