Genericity - putting it together

[vasslitvinov]

This issue asks how to put all the features together for a coherent update of our genericity story.

Here is my opening proposal:

• Require (?) when using a generic type, #21455
• Require ? for partial instantiations, #18665
• Require (?) when declaring a generic record or class - Approach 4 in #19120
• Require (?) for generic type things, #20473
• domain, range, integral, class, owned are to follow the general rules above.

Insights and further details:

• Since annotating ALL uses of generic classes/records with (?) is impractical/impossible, annotate them only in certain contexts. The set of contexts is T.B.D. based on Michael's good analysis in https://github.com/chapel-lang/chapel/issues/21455#issuecomment-1406632430

• In those contexts, require (?) regardless of the kind of type expression used, i.e., whether it is a class/record name, a type alias name, generic mem. management, function call. Uniformity leads to good language design, reduces the cognitive load of remembering special cases.

• Require ? for a partial instantiation in exactly the same context as the ones where we require (?) for a generic type, optionally allow elsewhere. This is to avoid user surprises "why I must use ? for this and not for that?"

• Allow optional (?) or ? in some? all? other cases of using a generic type or partial instantiation. This is to allow the code author to improve readability at their discretion. Also spare the user a trip to the documentation when they do not remember whether ? is required in a particular case.

• Annotating the definition of a record/class/type is the most direct way to achieve our goal of making it easier for the user to tell if something is generic.

• Is it a warning or an error when an annotation is missing or incorrect? T.B.D. separately; we are leaning towards error.

• (?) can be used in cases where the type expression could be either generic or concrete. It cannot be used when the type expression scope-resolves to a concrete type. We need this to handle the case, for example, where a function returns either a concrete or a generic type.

• I am not addressing: the proposal for () for fully-defaulted generics; the issues #19121 and #21456. Assuming status quo in those respects.

• What other aspects need to be included?

• These features are to be complemented by helpful error messages from the compiler.

Examples

// a generic class
class MyClass(?) {
  var field: MyRecord(?);
}

// a generic record
record MyRecord(?) {
  var field: borrowed MyClass?(?); // the first '?' is for nilability
  var field2: object?(?);        // the second '?' is for generic mem. management
}

// variables or consts; assuming split-initialization
var v1: MyRecord(?);
var v2: object?(?);
var v3: domain;       // warn/error: need domain(?) or domain(1) etc.
var v4: range;        // warn/error: need range(?) or range(int) etc.
var v5: domain(1);    // ok: fully instantiated using defaults
var v6: range(int,?); // ok: partial instantiation
var v7: rank * MyRecord(?); // a generic tuple
var v8: abc()(?);     // indicate that v8's declared type is generic

// var-like formals (not type/param)
proc p1( v1: MyRecord(?), v2: object?(?) ) {...}

// 'type' things

type t1(?) = MyRecord;   // '(?)' after MyRecord is not required here

class Class2(?) {
  type t2(?);            // t2 can be instantiated with a generic type
}

proc p2( type t2(?) ) {...}   // p2 can be invoked with a generic type

proc p3() type(?) {...}       // p3 can return a generic type

Afterword

The best path to move forward is to prototype these features and evaluate their impact.

[mppf]

record MyRecord(?) { ... }

I am concerned that this syntax will lead people to believe that they can define the type constructor in those parentheses, e.g. record MyRecord(type T) { ... } but as far as I know, you are not proposing that.

Put another way, places where (?) exist mean that you could put some other argument list there, but this proposal would change that.

[vasslitvinov]

No further changes are planned here for 2.0. I removed the 2.0 tag.