Need to reconsider fine points of instantiating a generic type in a way that makes method overloading ambiguous

bard_todo

How will you type-check this:

class A[T]{
  def m(T)=1;
  def m(Int)=2;
  static def example() {
    val t = new A[Int](); // you want this to be illegal, because t.m(1) is problematic
    example2[Int]();
  }
  static def example2[U]() {
    val t = new A[U](); // is this legal? will it cause a similar problem in the C++ backend?
    // t.m(1) is not problematic here because we resolve it to m(Int)=2
  }
}

For every class, we can build a list of problem instantiations (as a pseudo type constraint in terms of the type parameters, so we can catch overloading ambiguities between type parameters). Whenever classes or methods instantiate generic types based on their type parameters, they will inherit these restrictions on their type arguments as well. In this case, the error would be reported on both new A[Int]() and example2[Int]() — the first because of the direct conflict, and the second because example2() will inherit the restriction base(U)!=Int.

bulk defer of open issues to 2.2.2.

Dave, Igor: this jira is silent on why "complain-on-call" is problematic for the C++ backend.

Is it?

What are the problems?

(Bard – I dont understand your comment "Complain-on-instantiation can be checked in the front end, which ought to be easier and less troublesome than the back-end matters that complain-on-call requires." Both can be checked in the front end.)

I believe the issue is that when you instantiate a templatized C++ class, you have to instantiate all of its instance methods so the vtable can be filled in. If a particular instantiation of the class results in ambiguous methods, it doesn't matter whether or not the program actually ever calls them; the post compiler will reject the instantiation because it isn't valid C++.

We don't have this problem for static methods, since they get instantiated on a per-method basis (no vtable).

My recollection is that to support complain-on-call for instance methods we would need to give up on using the C++ object model to implement instance methods, and I don't see this as being a viable option.

I see. I agree that giving up the C++ object model is not a viable option.

Will the following definition suffice to rule out such C++ post-compilation errors? Recall that a unit is a class, struct or interface.

A unit definition U may include method definitions which are ambiguous for some choice of types for its type parameters. It is an error for a unit type to be such that all its instantiations have ambiguous members.

(Here, of course, we consider a type T to be an instance of T if T has no type parameters.)

This definition would mark Foo[S, T] as an error if it is defined thus:

class Foo[S,T]{S==T} {
  def m(S):void{}
  def m(T):void{}
}

Igor –

Have you thought through the design of the type constraints necessary (cf your message of May 29, 2011). This needs to be worked out carefully.

To make it concrete, here's an example of an X10 program that can't be supported with the current C++ codegen strategy. So, ideally we would reject this in the front end. The most precise checking of this would allow the call to trouble[Int,Double]() but reject the call to trouble[Int,Int]().

class Foo[S,T] {
  def m(S):void{ Console.OUT.println("S's m"); }
  def m(T):void{ Console.OUT.println("T's m"); }
}

public class GenericFun {
  public static def trouble[A,B]() = new Foo[A,B]();

  public static def main(Array[String]) {
    // this is ok
    trouble[Int,Double]();

    // this is not ok.
    //
    // Generated C++ code fails postcompilation because Foo[Int,Int]
    //   has two identical methods.
    // Does not matter that the methods are never called,
    // C++ needs to instantiate them to put them in the vtable.
    trouble[Int,Int]();
  }
}

The C++ level error when this class is compiled is as expected:

x10c++: In file included from GenericFun.cc:3:    
     /home/dgrove/x10-trunk/myTests/Foo.h: In instantiation of ‘Foo<int, int>’:    
     /home/dgrove/x10-trunk/myTests/GenericFun.h:71: instantiated from ‘static x10aux::ref<Foo<x10tp__S, x10tp__T> > GenericFun::trouble() [with x10tp__A = int, x10tp__B = int]’    
     GenericFun.cc:23: instantiated from here    
     /home/dgrove/x10-trunk/myTests/Foo.h:77: error: ‘void Foo<x10tp__S, x10tp__T>::m(x10tp__T) [with x10tp__S = int, x10tp__T = int]’ cannot be overloaded    
     /home/dgrove/x10-trunk/myTests/Foo.h:69: error: with ‘void Foo<x10tp__S, x10tp__T>::m(x10tp__S) [with x10tp__S = int, x10tp__T = int]’    

This simple case could be caught by analyzing Foo and having the compiler add the constraint S!=T to the class invariants. One can also construct variations like:

class Foo[S,T] {
  def m(S):void{ Console.OUT.println("S's m"); }
  def m(T):void{ Console.OUT.println("T's m"); }
  def m(Complex):void { ... }
}

So you would need S!=T and S!=Complex and T!=Complex in the class invariants.

It might be possible for the typechecker to formulate all the necessary constraints by looking at overloaded virtual methods that have type parameters as arguments. I haven't worked out the details (and they may be too complex to make it practical), but I think that is probably the only solution that will catch all potential post-compilation errors at X10 compile time and safely allow overloading of instance methods whose formal types include a type parameter of the class.

So you would need S!=T and S!=Complex and T!=Complex in the class invariants.

Actually, that is not enough. Because constraints are stripped away, you would need to express (S!=T)_{mod constraints}. Last year I proposed both the != operation for types, and the RawType operator (or whatever name we choose to give it). I also proposed a CanBeOverloaded predicate on two types, with essentially the above motivating example. Both were rejected.

bulk defer of 2.3.0 open issues to 2.3.1.

bulk defer to 2.3.2