Should type t:someType arguments allow coercion?

[mppf]

Consider this example program:

proc foo(type t:int) {
  writeln("int version");
}
foo(int(8));

Currently this program compiles and resolves. But that reflects the fact that int(8) can coerce to int(64). Should this be allowed?

[bradcray]

Intuitively, I'd think "no", but at the same time, I'm not sure what saying type t: int ought to mean in this context. "You can pass in any type 't' as long as it's int" doesn't seem very interesting.

I would expect type t: int(?t) to support passing in any int type...

[mppf]

"You can pass in any type 't' as long as it's int" doesn't seem very interesting.

It is interesting for things like casts, where you want to override a generic function that takes in a type argument to apply to a specific type.

E.g. in ChapelBase.chpl right now, we have

  inline proc chpl_typeSupportsPrimitiveCast(type t) param
    return isBoolType(t) ||
           isIntegralType(t) ||
           isRealType(t);

  inline proc _cast(type t, x: int(?w)) where chpl_typeSupportsPrimitiveCast(t)
    return __primitive("cast", t, x);

We might contemplate rewriting that like this:

  inline proc _cast(type t:bool(?a), x: int(?b))
    return __primitive("cast", t, x);

  inline proc _cast(type t:int(?a), x: int(?b))
    return __primitive("cast", t, x);

  inline proc _cast(type t:uint(?a), x: int(?b))
    return __primitive("cast", t, x);

  inline proc _cast(type t:real(?a), x: int(?b))
    return __primitive("cast", t, x);

If we did, AFAIK the compiler would actually create overloads for all of the ?a / ?b combinations directly (instead of leaving them generic). And then we'd have (at some point) a function like

  inline proc _cast(type t:int(32), x: int(8))
    return __primitive("cast", t, x);

which is exactly the "Doesn't seem very interesting" case in that it only accepts a single type for the type argument.

[bradcray]

I see, thanks for the additional context. I think I still believe that the int(8) type shouldn't coerce to a type argument expecting an int(64).

[mppf]

I'm currently thinking that disallowing coercion for type arguments makes them behave more naturally, since the common case for a type argument probably is to create a generic function - and in that setting, the generic will be instantiated with the actual type (i.e. there won't be any coercions). Additionally I recently saw _new candidates for parent class types being considered in disambiguation, which is probably not intended.

It's still the case though that you can have something like this (from the test type-colon-generic-record.chpl):

record R {
  var x;
}

proc foo(type t:R) {
  writeln("generic ", t:string);
}
proc foo(type t:R(real)) {
  writeln("real ", t:string);
}


var r1=new R(1);
var rs=new R("test");
var rr=new R(1.0);

foo(r1.type);
foo(rs.type);
foo(rr.type);

which compiles and runs; the 3rd call to foo runs the "real" version.

I think that makes sense because it matches how generic instantiation works / how a generic function with a where clause would work.