16985, “vasslitvinov”, “CG: mixing with unconstrained generics (UG)?”, “2021-01-22T06:19:50Z”
main issue: #8629
This issue discusses the need to allow unconstrained generics when rewriting the sort function as a CG.
Background “Unconstrained generics” (UG) is the term we use currently to describe the “classic” generics in Chapel. A key difference is:
- An UG function is resolved specifically for a given instantiation. It is resolved as if it is a concrete function. For example, applicable candidates for a function call are chosen with full knowledge of the call’s instantiated argument types.
- A CG function is resolved independently of any instantiation. The only applicable candidates for calls involving constrained types are those available in the corresponding interface(s).
Both UG and CG functions can have where-clauses. A where-clause for a CG function has “interface constraints”, for example:
proc f(arg: ?T) where T implements MyInterface {...}
whereas an UG function’s where-clause cannot have interface constraints.
Background Currently the basic sorting function (see the docs) is written as:
proc sort(Data: [?Dom] ?eltType, comparator: ?rec = defaultComparator)
We are considering the following ways to rewrite it with CG:
// The interface specifies the comparison operation.
proc sort(Data: [?Dom] ?eltType) where eltType implements Comparable
// The interface describes the comparator object.
proc sort(Data: [?Dom] ?eltType, comparator: ?C) where C implements Comparator(eltType)
In both cases, the sorting function is generic over the domain of the array it accepts.
Question How to handle these two sources of genericity?
So far we have aimed at avoiding a mix of CG and UG.
The CG versions of sort() go against this restriction.