Proposal: Constructor type argument inference

[alrz]

Constructor type argument inference

Consider T is a name with arity zero.

new T()

Only if the existing rules are unable to find a constructor to bind, we continue to the next step to retain backward compatibility. In other words, we do so if either of the following conditions are true:

• (1) the name T does not exist or is inaccessible
• (2) the name T is (a) not a class or struct (b) not a type parameter
  • (2a) the type T is static or abstract
  • (2b) the type parameter T does not have a constructor or struct constraint
• (3) the overload resolution fails to select a single best candidate

After that, we gather all the types in scope with the same name regardless of the arity (the arity here would be always greater than zero, because we already tried all names with the arity zero). Then we add all accessible constructors to a set of candidates and run an overload resolution pass. For example, considering:

class C<T> {
  public C(...) {}
  public C(...) {}
  // ...
}    

class C<T, U> {
  public C(...) {}
  public C(...) {}
  // ...
}

We resolve new C(...) just like how we do generic method overload resolution,

public void C<T>(...) {}
public void C<T>(...) {}
public void C<T, U>(...) {}
public void C<T, U>(...) {}

C(...);

At the end, if no unfixed type parameters exist then type inference (and the overload resolution) succeeds and we have a single best constructor to be invoked.

Note that "closeness" rules are at play as well, so when we gather generic types, we do so step-by-step for types that are closer to the call-site.

For example, we resolve new C(42) in the following code:

namespace A {
  public class C<T> {
    public C(T a) {}
  }
}

namespace A.B {
  public class C<T> {
    public C(T a) {}
  }
}

namespace A.B.C {
  class Foo {
    Foo() {
      new C(42);  
    }
  }
}

Just like we resolve C(42) in the following:

class A {
  public void C<T>(T a) {}
}

class B : A {
  public void C<T>(T a) {}
}

class Foo : B {
  Foo() {
    C(42);
  }
}

Therefore, it would not be ambiguous.

Collection Initializers

If the type arguments couldn't be inferred, in the presence of collection initializers, we will try to run the same pass on Add methods. So new List { 1, 2, 3 } works as expected.

Currently, a collection initializer is allowed to call different Add overloads based on each element type. To keep the rules simple, we only consider the first element of the initializer when we run the overload resolution pass to resolve the type, and produce error for other elements, if needed.

For example, we would fail to infer C<int> for new C { { 1, 2 }, 2 }; here:

class C<T> {
  public void Add(T t) {}
  public void Add(int a, int b) {}
}
class C<T, U> {
  public void Add((T, U) t) {}
  public void Add(T a, U b) {}
}

Because the matching overload for the first element does not fix the type parameter T.

Obejct Initializers

We won't depend on the object initializers to infer any type argument, so an object initializer is permitted only if all type arguments are already inferred from provided arguments.

Alternatives

When we gather all constructors to the candidate set, there could be conflicting overloads, and if that happened, those should be removed from the set. Alternatively, we could consider "omitted type arguments" to specify the arity without mentioning the type arguments, e.g. new C<,>() so we don't have to do a complex name resolution to determine the arity. Just that we will try to infer type arguments from the constructor arguments or the collection initializer, if any.

Vartiations

A similar approach could be taken to infer type arguments on static method invocations.

class C<T> {
  public static void M(T x) {}
}

C.M(42);
C<>.M(42);

[svick]

So if there exist multiple type with the same name it wouldn't be possible to use type inference in the use-site.

Does this mean the new Nullable(1) example would not work, since there is a non-generic Nullable type (even if it's static)?

[jnm2]

Does this mean the new Nullable(1) example would not work, since there is a non-generic Nullable type (even if it's static)?

I would be seriously unhappy if it did. 😆

[alrz]

@svick

That depends on factors that contribute to the type inference. Being static is a good example. I'll try to add more details over time.

Update: updated.

[hickford]

Would this proposal allow me to write eg. new Lazy(Path.GetTempFileName) instead of new Lazy<string>(Path.GetTempFileName)?

[alrz]

@hickford That's another issue with type inference. See #129. I haven't suggested any changes to type inference with method groups here.

Correction: Since the following works, I'd say yes you can do that.

void M<T>(Func<T> f) {}

M(Path.GetTempFileName);

[alrz]

Taking a look at F# spec, it uses a simpler rule for the name resolution, it only fallbacks to the generic type when there's only a single one, so new C(..) or C.M(..) for class C<T> would only work if C<T> is the only generic type in scope. And then it tries to infer type arguments from argument list of the constructor or the method call (in case the type appeared as the receiver of an invocation).