20473, "vasslitvinov", "should it be clearer when a 'type' is generic?", "2022-08-19T04:29:46Z"
Related: #19120 and #19121
Background: this came from my prototyping of "Proposal 4" in 'Range' vs. 'domain': concrete / generic by default? · Issue #17122 · chapel-lang/chapel · GitHub , namely making the range type fully generic by removing the defaults for all of its three fields. I started getting errors akin to "cannot create an array of a generic type" in situations where the generic type comes from client code. Given that our compiler's errors are sometimes confusing, which in some cases reflects the difficulty of figuring out where the actual error is, I propose to give users a tool to require non-generic types. It is analogous to an interface in helping make it clear whether the error is on the library side vs. on the application side.
This proposal is that the type keyword means "this must be a concrete type" in these cases:
- a
typealias, ex.type R = range; - a
typeformal, ex.proc p(type T) - a
typereturn intent, ex.proc t() type
If the user wants to allow generic types in these contexts, they would need to use different syntax, for example a different keyword or type(?) :
type(?) GR = range(int, ?);proc p(type(?) T)proc p() type(?)
I expect the case "this may be a generic type" to be rare, so there will be few changes to existing codes, if any.
I propose that this alternative syntax accepts concrete types as well, for example to avoid code changes when a generic type becomes concrete due to other code changes.