>
> (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_.
