Questions on Template Classes proposal

Brian Goetz brian.goetz at
Thu Mar 14 13:14:59 UTC 2019

> (What's an optional member of a template?  Ah, that's a good
> conversation.  I haven't written this one up yet.  I think the cleanest
> way to formulate those is in terms of *optional child segments*.
> I can think of many different ways to gate their optionality,
> and BSM-based instantiation is probably the most general
> and therefore adequate.)

I have opinions about this ….

In the language, optional membership will be based on computations deriving from holes.  For example, we might have a conditional method

    <when T implements Monoid<T>> 
    T sum()

The `T implements Monoid<T>` is something that can be computed by a condy that evaluates down to a boolean, so I think its fair to say that optionality can be gated by a boolean constant.  And given that optional members will likely go together, we can make a child segment containing all the members gated by common predicates.  

This is a boon for type checking / verification, since a method conditional on a predicate might well invoke another method conditional on that predicate (or a sub-predicate) or access a conditional field.  By grouping into segments, then we never have to worry about a member in species Foo<T> accessing another member that is not part of Foo<T>.  

> I don't see a general solution for MI, and so I'd prefer to define a
> very specific new kind of inheritance, from a "template super",
> as discussed above.  

To put a pin in: I think we’re going to want a notion of “static interface super” as well, which is an interface contract that we expect the class literal to adhere to.  (This is how we get to, for example, operator overloading, or the conditional `T extends Monoid<T>` example above.)  Basically, using interfaces to describe a set of _class behaviors_ as well as the usual set of _instance behaviors_.  

More information about the valhalla-spec-observers mailing list