Questions on Template Classes proposal

[John Rose]

Yes from me to all your points here. 

A conditional child segment doesn’t need any new holes, just there BSM based predicate you mention. This works equally well for conditional fields, methods, and nested types. 

Conditional supers seem to require some special pleading with DefaultType to carry the conditional type; or else pure reflective class spinning; not sure about the best way. Probably a separately templatable super_info struct would be cleanest. 

> On Mar 14, 2019, at 6:14 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
>> 
>> (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_.  
>