Proposal: Partial type inference

[TomatorCZ]

Partial type inference

• Proposed
• Prototype
• Implementation
• Specification

Note: This proposal was created because of championed Partial type inference. It is a continuation of the proposed first version published in csharplang/discussions

Summary

Partial type inference introduces a syntax skipping obvious type arguments in the argument list of

1. invocation_expression
2. object_creation_expresssion

and allowing to specify just ambiguous ones.

It also improves the type inference in the case of object_creation_expression by leveraging type bounds obtained from the target, object_or_collection_initializer, and type_parameter_constraints_clauses.

Besides the changes described above, the proposal mentions further interactions and possibilities to extend the partial type inference.

Motivation

• The current method type inference works as an "all or nothing" principle.
  If the compiler is not able to infer command call type arguments, the user has to specify all of them.
  This requirement can be verbose, noisy, and unnecessary in cases where the compiler can infer almost all type arguments and need just to specify ambiguous ones.
• The need to hint types to the compiler is influenced by the strength of the type inference which is not as advanced as in other statically-typed languages like Rust or Haskell.
  However, we can't just change the current behavior of the type inference because it would introduce breaking changes.
  What we can do is to introduce improved type inference in places, where it was not before like object_creation_expression.
  It is a nice chance to push the type inference to the next level without introducing breaking changes.
  And then wait for the time, when C# would be ready to introduce breaking changes without any major disadvantages.
• Because there exist types containing many type parameters (especially in frameworks focusing on databases and web), it would be great to add type inference of constructors to save unnecessary specifying the type arguments.

No matter how the partial type inference would work, we should be careful about the following things.

• Convenience - We want an easy and intuitive syntax that we can skip the obvious type arguments.
• Performance - Type inference is a complicated problem when we introduce subtyping and overloading in a type system.
  Although it can be done, the computation can take exponential time which we don't want.
  So it has to be restricted to cases, where the problem can be solved effectively but it still has practical usage.
• IDE - Improvement of the type inference can complicate IDE hints during coding.
  We should give the user clear and not overwhelming errors when there will be an error and try to provide info that helps him to fix it.
• Extensions - We don't want to make this change blocker for another potential feature in the future.
  So will want to look ahead to other potential directions, which can be done after this feature.

Detailed design

Grammar

The following changes are made in tokens located in the grammar section.

Identifiers

• The semantics of an identifier named _ depends on the context in which it appears:
  • It can denote a named program element, such as a variable, class, or method, or
  • It can denote a discard (§9.2.9.1).
  • It can denote an inferred type argument avoiding specifying type arguments which can be inferred by the compiler.

Keywords

• A contextual keyword is an identifier-like sequence of characters that has special meaning in certain contexts, but is not reserved, and can be used as an identifier outside of those contexts as well as when prefaced by the @ character.

  contextual_keyword
      : 'add'    | 'alias'      | 'ascending' | 'async'     | 'await'
      | 'by'     | 'descending' | 'dynamic'   | 'equals'    | 'from'
      | 'get'    | 'global'     | 'group'     | 'into'      | 'join'
      | 'let'    | 'nameof'     | 'on'        | 'orderby'   | 'partial'
      | 'remove' | 'select'     | 'set'       | 'unmanaged' | 'value'
  +   | 'var'    | 'when'       | 'where'     | 'yield'     | '_'
  -   | 'var'    | 'when'       | 'where'     | 'yield'
    ;

Type arguments

• We change the meaning of the content of type_argument_list in two contexts.

  • Constructed types occuring in object_creation_expression
  • Constructed types and type arguments occuring in method invocation

• inferred_type_argument represents an unknown type, which will be resolved during type inference.

• _ identifier is considered to represent inferred_type_argument when:

  • It occurs in type_argument_list of a method group during method invocation.
  • It occurs in type_argument_list of a type in object_creation_expression.
  • It occurs as an arbitrary nested identifier in the expressions mentioned above.

  Example

  F<_, int>(...); // _ represents an inferred type argument.
  new C<_, int>(...); // _ represents an inferred type argument.
  F<C<_>, int>(...); // _ represents an inferred type argument.
  new C<C<_>, int>(...); // _ represents an inferred type argument.
  C<_> temp = ...; // _ doesn't represent an inferred type argument.
  new _() // _ doesn't represent an inferred type argument.

• A method group and type are said to be partial_inferred if it contains at least one inferred_type_argument.

• A type is said to be generic_inferred when all the following hold:

  • It has an empty type_argument_list.
  • It occurs as a type of object_creation_expression.

  Example

  new C<>() // C is generic_inferred.
  new C<G<>>() // C nor G are generic_inferred.
  F<>() // F isn't generic_inferred.

Namespace and type names

Determining the meaning of a namespace_or_type_name is changed as follow.

• If a type is a generic_inferred, then we resolve the identifier in the same manner except ignoring the arity of type parameters (Types of arity 0 is ignored).
  If there is an ambiguity in the current scope, a compilation-time error occurs.

  Example

  class P1
  {
      void M() 
      {
          new C1<>(); // Refers generic_inferred type C1<T>
          new C2<>(); // Refers generic_inferred type C2<T1,T2>
      }
      class C1<T> {}
      class C2<T1, T2> {}
  }
  class P2
  {
      void M() 
      {
          new C1<>(); // Compile-time error occurs because of ambiguity between C1<T> and C1<T1, T2>
      }
      class C1<T> {}
      class C1<T1, T2> {}
  }

Method invocations

The binding-time processing of a method invocation of the form M(A), where M is a method group (possibly including a type_argument_list), and A is an optional argument_list is changed in the following way.

The initial set of candidate methods for is changed by adding new condition.

• If F is non-generic, F is a candidate when:
  • M has no type argument list, and
  • F is applicable with respect to A (§12.6.4.2).
• If F is generic and M has no type argument list, F is a candidate when:
  • Type inference (§12.6.3) succeeds, inferring a list of type arguments for the call, and
  • Once the inferred type arguments are substituted for the corresponding method type parameters, all constructed types in the parameter list of F satisfy their constraints (§8.4.5), and the parameter list of F is applicable with respect to A (§12.6.4.2)
• If F is generic and M has type argument list containing at least one inferred_type_argument, F is a candidate when:
  • Type inference (§12.6.3) succeeds, inferring a list of inferred_type_arguments for the call, and
  • Once the inferred_type_arguments are inferred and together with remaining type arguments are substituted for the corresponding method type parameters, all constructed types in the parameter list of F satisfy their constraints (§8.4.5), and the parameter list of F is applicable with respect to A (§12.6.4.2)
• If F is generic and M includes a type argument list, F is a candidate when:
  • F has the same number of method type parameters as were supplied in the type argument list, and
  • Once the type arguments are substituted for the corresponding method type parameters, all constructed types in the parameter list of F satisfy their constraints (§8.4.5), and the parameter list of F is applicable with respect to A (§12.6.4.2).

Object creation expressions

The binding-time processing of an object_creation_expression of the form new T(A), where T is a class_type, or a value_type, and A is an optional argument_list, is changed in the following way.

Note: Type inference of constructor is described later in the type inference section.

The binding-time processing of an object_creation_expression of the form new T(A), where T is a class_type, or a value_type, and A is an optional argument_list, consists of the following steps:

• If T is a value_type and A is not present:
  • The object_creation_expression is a default constructor invocation.
    • If the type is generic_inferred or partially_inferred, type inference of the default constructor occurs to determine the type arguments. If it succeeded, construct the type using inferred type arguments. If it failed and there is no chance to get the target type now or later, the binding-time error occurs. Otherwise, repeat the binding when the target type will be determined and add it to the inputs of type inference.
    • If the type inference above succeeded or the type is not inferred, the result of the object_creation_expression is a value of (constructed) type T, namely the default value for T as defined in §8.3.3.
• Otherwise, if T is a type_parameter and A is not present:
  • If no value type constraint or constructor constraint (§15.2.5) has been specified for T, a binding-time error occurs.
  • The result of the object_creation_expression is a value of the run-time type that the type parameter has been bound to, namely the result of invoking the default constructor of that type. The run-time type may be a reference type or a value type.
• Otherwise, if T is a class_type or a struct_type:
  • If T is an abstract or static class_type, a compile-time error occurs.
  • The instance constructor to invoke is determined using the overload resolution rules of §12.6.4. The set of candidate instance constructors is determined as follows:
    • T is not inferrred (generic_inferred or partially_inferred), the constructor is accessible in T, and is applicable with respect to A (§12.6.4.2).
    • If T is generic_constructed or partially_constructed and the constructor is accessible in T, type inference of the constructor is performed. Once the inferred_type_arguments are inferred and together with the remaining type arguments are substituted for the corresponding type parameters, all constructed types in the parameter list of the constructor satisfy their constraints, and the parameter list of the constructor is applicable with respect to A (§12.6.4.2).
  • A binding-time error occurs when:
    • The set of candidate instance constructors is empty, or if a single best instance constructor cannot be identified, and there is no chance to know the target type now or later.
  • If the set of candidate instance constructors is still empty, or if a single best instance constructor cannot be identified, repeat the binding of the object_creation_expression to the time, when target type will be known and add it to inputs of type inference.
  • The result of the object_creation_expression is a value of type T, namely the value produced by invoking the instance constructor determined in the two steps above.
  • Otherwise, the object_creation_expression is invalid, and a binding-time error occurs.

Type inference

We change the type inference as follows.

• Type inference for generic method invocation is performed when the invocation:

  • Doesn't have a type_argument_list.
  • The type argument list contains at least one inferred_type_argument.

  Example

  M(...); // Type inference is invoked.
  M<_, string>(...); // Type inference is invoked.
  M<List<_>, string>(...); // Type inference is invoked.

• Type inference for constructors is performed when the generic type of object_creation_expression:

  • Has a diamond operator.
  • Its type_argument_list contains at least one inferred_type_argument.

  Example

  new C<>(...); // Type inference is invoked.
  new C<_, string>(...); // Type inference is invoked.
  new C<List<_>, string>(...); // Type inference is invoked.

• When the method invocation contains a type argument list containing inferred type argument, the input for type inference is extended as follows:

  • We replace each _ identifier with a new type variable X.
  • We perform shape inference from each type argument to the corresponding type parameter.

• Inputs for constructor type inference are constructed as follows:

  • If the inferred type contains a nonempty type_argument_list, we process it in the same manner as in the method invocation.
  • If the target type should be used based on the expression binding, perform upper-bound inference from it to the type containing the constructor
  • If the expression contains an object_initializer_list, for each initializer_element of the list perform lower-bound inference from the type of the element to the type of initializer_target. If the binding of the element fails, skip it.
  • If the expression contains where clauses defining type constraints of type parameters of the type containing constructor, for each constraint not representing constructor constrain, reference type constraint, value type constraint and unmanaged type constraint perform lower-bound inference from the constraint to the corresponding type parameter.
  • If the expression contains a collection_initializer_list and the type doesn't have overloads of the Add method, for each initializer_element of the list perform lower-bound inference from the types of the elements contained in the initializer_element to the types of the method's parameters. If the binding of any element fails, skip it.
  • If the expression contains a collection_initializer_list using an indexer, use the indexer defined in the type and perform lower_bound_inference from the types in initializer_element to types of matching parameters of the indexer.

• Arguments binding

  • It can happen that an argument of an expression will be object_creation_expression, which needs a target type to be successful binded.
  • In these situations, we behave like the type of the argument is unknown and bind it when we will know the target type.
  • We treat it in the same manner as an unconverted new() operator.

Type inference algorithm change

• Shape dependence

  • An unfixed type variable Xᵢ shape-depends directly on an unfixed type variable Xₑ if Xₑ represents inferred_type_argument and it is contained in shape bound of the type variable Xᵢ.
  • Xₑ shape-depends on Xᵢ if Xₑ shape-depends directly on Xᵢ or if Xᵢ shape-depends directly on Xᵥ and Xᵥ shape-depends on Xₑ. Thus “shape-depends on” is the transitive but not reflexive closure of “shape-depends directly on”.

• Type dependence

  • An unfixed type variable Xᵢ type-depends directly on an unfixed type variable Xₑ if Xₑ occurs in any bound of type variable Xᵢ.
  • Xₑ type-depends on Xᵢ if Xₑ type-depends directly on Xᵢ or if Xᵢ type-depends directly on Xᵥ and Xᵥ type-depends on Xₑ. Thus “type-depends on” is the transitive but not reflexive closure of “type-depends directly on”.

• Shape inference

  • A shape inference from a type U to a type V is made as follows:
    • If V is one of the unfixed Xᵢ then U is a shape bound of V.
    • When a shape bound U of V is set:
      • We perform upper-bound inference from U to all lower-bounds of V, which contains an unfixed type variable
      • We perform exact inference from U to all exact-bounds of V, which contains an unfixed type variable.
      • We perform lower-bound inference from U to all upper-bounds of V, which contains an unfixed type variable.
      • We perform lower-bound inference from all lower-bounds of V to U if U contains an unfixed type variable.
      • We perform exact inference from all exact-bounds of V to U if U contains unfixed type variable.
      • We perform upper-type inference from all upper-bounds of V to U if U contains an unfixed type variable.
    • Otherwise, on inferences are made

• Lower-bound inference

  • When a new bound U is added to the set of lower-bounds of V:
    • We perform lower-bound inference from U to the shape of V , if it has any and the shape contains an unfixed type variable.
    • We perform upper-bound inference from the shape of V to U, if V has a shape and U contains an unfixed type variable.
    • We perform exact inference from U to all lower-bounds of V, which contains an unfixed type variable
    • We perform lower-bound inference from U to all exact-bounds and upper-bounds of V, which contains an unfixed type variable.
    • We perform exact inference from all lower-bounds of V to U if U contains an unfixed type variable
    • We perform upper-bound type inference from all exact-bounds and upper-bounds of V to U if U contains unfixed type variable.

• Upper-bound inference

  • When new bound U is added to the set of upper-bounds of V:
    • We perform upper-bound inference from U to the shape of V , if it has any and the shape contains an unfixed type variable.
    • We perform lower-bound inference from the shape of V to U, if V has a shape and U contains an unfixed type variable.
    • We perform exact inference from U to all upper-bounds of V, which contains an unfixed type variable
    • We perform upper-bound inference from U to all exact-bounds and lower-bounds of V, which contains an unfixed type variable.
    • We perform exact inference from all upper-bounds of V to U if U contains an unfixed type variable
    • We perform lower-bound type inference from all exact-bounds and lower-bounds of V to U if U contains unfixed type variable.

• Exact inference

  • When new bound U is added to the set of lower-bounds of V:
    • We perform exact-bound inference from U to the shape of V , if it has any and the shape contains an unfixed type variable.
    • We perform exact inference from the shape of V to U, if V has a shape and U contains an unfixed type variable.
    • We perform exact inference from U to all exact-bounds of V, which contains an unfixed type variable
    • We perform lower-bound inference from U to all lower-bounds of V, which contains an unfixed type variable
    • We perform upper-bound inference from U to all upper-bounds of V, which contains an unfixed type variable
    • We perform exact inference from all exact-bounds of V to U, which contains an unfixed type variable
    • We perform upper-bound inference from all lower-bounds of V to U, which contains an unfixed type variable
    • We perform lower-bound inference from all upper-bounds of V to U, which contains an unfixed type variable

• Second phase

  • Firstly, all unfixed type variables Xᵢ which do not depend on (§12.6.3.6), shape-depend on, and type-depend on any Xₑ are fixed (§12.6.3.12).
  • If no such type variables exist, all unfixed type variables Xᵢ are fixed for which all of the following hold:
    • There is at least one type variable Xₑ that depends on, shape-depends on, or type-depends on Xᵢ
    • There is no type variable Xₑ on which Xᵢ shape-depends on.
    • Xᵢ has a non-empty set of bounds and has at least on bound which doesn't contain any unfixed type variable.
  • Otherwise continue as the standard says.

• Fixing

  • An unfixed type variable Xᵢ with a set of bounds is fixed as follows:
    • If the type variable has a shape bound, check the type has no conflicts with other bounds of that type variable in the same way as the standard says. It it has no conflicts, the type variable is fixed to that type. Otherwise type inference failed.
    • Otherwise, fix it as the standard says.

Type inference for constructor

Note: Complexity

Because performing type inference can even take exponential time when a type system contains overloading, the restriction was made above to avoid it.
It regards to permit only one method Add in the collections and binding arguments before the overload resolution when we bind all object_creation_expressions without target info and then in case of overload resolution success and some of these arguments failed in the binding, we try to bind it again with already known target type information.

Compile-time checking of dynamic member invocation

We change the compile-time checking in order to be useful during partial type inferece.

• First, if F is a generic method and type arguments were provided, then those, that aren't inferred_type_argument are substituted for the type parameters in the parameter list. However, if type arguments were not provided, no such substitution happens.
• Then, any parameter whose type is open (i.e., contains a type parameter; see §8.4.3) is elided, along with its corresponding parameter(s).

Nullability

We can use an examination mark ? to say that the inferred type argument should be a nullable type (e.g. F<_?>(...)).

Drawbacks

Why should we not do this?

Alternatives

What other designs have been considered? What is the impact of not doing this?

Unresolved questions

• Type inference for arrays

  In a similar way as we propose partial type inference in method type inference.
  It can be used in array_creation_expression as well (e.g. new C<_>[]{...}).
  However, It has the following complication.
  To avoid a breaking change, the type inference has to be as powerful as in method type inference. There is a question if it is still as valuable as in cases with methods.

• Type inference for delegates

  We can do the same thing for delegate_creation_expression. However, these expressions seems to be used rarely, so is it valuable to add the type inference for them as well ?

• Type inference for local variables

  Sometimes var keyword as a variable declaration is not sufficient.
  We would like to be able to specify more the type information about variable but still have some implementation details hidden.
  With the _ placeholder we would be able to specify more the shape of the variable avoiding unnecessary specification of type arguments.

  Wrapper<_> wrapper = ... // I get an wrapper, which I'm interested in, but I don't care about the type arguments, because I don't need them in my code.
  wrapper.DoSomething();

• Type inference for casting

  This can be useful with combination with already preparing collection literals.

  var temp = (Span<_>)[1,2,3];

• Is there a better choice for choosing the placeholder for inferred type argument ?

  Potentional resolution: My choice contained in the detailed design is based on the following.

Details

We base our choice on the usages specified below.

1. Type argument list of generic method call (e.g. Foo<T1, T2>(...))
2. Type argument list of type creation (e.g. new Bar<T1, T2>(...))
3. Type argument list of local variable (e.g. Bar<T1, T2> temp = ...)
4. Expressing array type (e.g. T1[])
5. Expressing inferred type alone T1 in local variable

Diamond operator

1. In the case of generic method calls it doesn't much make sense since method type inference is enabled by default without using angle brackets.

Foo<>(arg1, arg2, arg3); // Doesn't bring us any additional info

2. There is an advantage. It can turn on the type inference. However, it would complicate overload resolution because we would have to search for every generic type of the same name no matter what arity. But could make a restriction. Usually, there is not more than one generic type with the same name. So when there will be just one type of that name, we can turn the inference on.

new Bar<>(); // Many constructors which we have to investigate for applicability
new Baz<>(); // Its OK, we know what set of constructors to investigate.

class Bar { ... }
class Bar<T1> { ... }
class Bar<T1, T2> { ... }

class Baz<T1,T2> {...}

3. It could make sense to specify just a wrapper of some type that gives us general API that doesn't involve its type arguments. It would say that the part of the code just cares about the wrapper. However, we think that it doesn't give us much freedom because type arguments usually appear in public API and only a few of them are for internal use.

Wrapper<> temp = ...

4. It doesn't seem very well.

<>[] temp = ...

5. It clashes with var and looks wierd.

<> temp = ... // equivalent to `var temp = ...`

Whitespace seperated by commas

1. It is able to specify the arity of the generic method. However, it seems to be messy when it is used in generic methods with many generic type parameters. Also, it already has its own meaning of expressing open generic type.

Foo<,string,List<>,>(arg1, arg2, arg3);

1. The same reasoning as above.

new Bar<,string,List<>,>(arg1, arg2) { arg3 };

3. It doesn't work with array type.

Bar<,string,List<>,> temp = ...

4. It doesn't seems very well.

[] temp = ...
Foo<,[],>(arg1, arg2)

5. It looks like CSharp would not be a statically-typed language, clashed with var and probably introduce many implementation problems in the parser.

temp = ...

_ seperated by commas

1. It specifies the arity of the generic method. It explicitly says that we want to infer this type argument. It seems to be less messy.

Foo<_, string, List<_>, _>(arg1, arg2, arg3);

2. The same reasons as above.

new Bar<_, string, List<_>, _>(arg1, arg2, arg3);

3. The same reasons as above.

Bar<_, string, List<_>, _>(arg1, arg2);

4. Looks quite OK.

_[] temp = ...

5. Clashes with var and seems to be wierd.

_ temp = ...

var seperated by commas

1. More keystrokes. It starts to raise the question if it brings the advantage of saving keystrokes.

Foo<var, string, List<var>, var>(arg1, arg2, arg3);

2. The same reasons as above

new Bar<var, string, List<var>, var>(arg1, arg2, arg3);

3. The same reasons as above.

Bar<var, string, List<var>, var>(arg1, arg2);

1. Looks OK.

var[] temp = ...

5. State of the art.

var temp = ...

Something else seperated by commas

Doesn't make a lot of sense because it needs to assign new meaning to that character in comparison with _, var, <>, <,,,>.
Asterisk * can be considered, however, it can remind a pointer.

Conslusion

I prefer _ character with enabling <> operator in the case of constructor inference when there is only one generic type with that name.
Additionally to that, I would prohibit using _ in the same places as var.

Design meetings

Link to design notes that affect this proposal, and describe in one sentence for each what changes they led to.

[jcouv]

Thanks for trying to show the proposed change in context of the existing spec. It would be helpful to further highlight the portions that changes (\***...** is how I usually try to do that).
I'll have to spend more time digging into the type inference section to reload some context (it's a bit hairy).

The way I see it, there's three layers to this proposal:

1. adding support for _ in method type inference (this is the core/original proposal)
2. adding support for type inference in object creation with _ (number of type arguments still known, which means the arity/type is known)
3. adding support for type inference in object creation with <> (introduces additional issue with selecting amongst multiple types, since arity isn't known)

Thoughts on part 1 (method type inference)

I'll need to read this in more details. I expected to see the changes to candidate selection and type parameter fixing (type inference phase 2), but I didn't quite get why we need the new concepts of shape-dependence and type-dependence.

Thoughts on parts 2 and 3 (object creation)

Applying method type inference to object creation

Inputs for constructor type inference are constructed as follows:

• If the inferred type contains a nonempty type_argument_list, we process it in the same manner as in the method invocation.
  [...]

This probably needs more details.

The current spec handles object creation in the following way: "The set of candidate instance constructors consists of all accessible instance constructors declared in T, which are applicable with respect to A."

But in the new T<>(A) scenario, we won't know which type T were referring to. You can have:

new C<>(42);
class C { ... }
class C<T> { ... }
class C<T1, T2> { ... }

In such case, the constructors from multiple types have to be considered in one go, so that text needs to be amended.

Also, the inference (from arguments to type arguments) won't apply to constructors, but to the type itself, which is different than method invocation. So we would infer C<int>..ctor(42) for instance, as opposed to C.M<int>(42) for methods.

When going down that line, it raises the question: would type inference apply to containing types? e.g. new Containing<>.Nested<>(42)

Clarifying an early example

I was confused by an early example:

class P1
{
    void M() 
    {
        new C1<>(); // Refers generic_inferred type C1<T>
    }
    class C1<T> {}
    class C2<T1, T2> {}
}

That seems wrong. The type parameter T isn't even in scope at that location and no arguments were provided to the object creation, so I don't think we can infer type arguments here.
So I think that line should fail. Did I miss something?

[TomatorCZ]

Hi,

thank you for your feedback.
Sorry for the late reaction.

I will fix the mentioned issues in the next round(It should be placed here as well or as another discussion?).

I will try to answer your questions:

Part 1

Besides candidate selection and type parameter fixing, we have to also improve the inference itself.
Now, the inferred bounds can contain other unfixed type variables.
So we have to propagate the type info also through these bounds.

Example

    void F<T1> (T1 p1) { ... }
...
    F<IList<_>>(new List<int>());

We have now two type variables T1 and _. From the first bound, we get that IList<_> is a shape bound of T1(Ignore now the type of bound, it would be the same in other types of bound).
When we investigate the second bound List<int>, we will figure out that it would be a lower bound of T1.
But now, we have to somehow propagate the int type to the _ type variable, because it relates to it.
That means, in the process of adding new bounds, we have to also propagate this info through bounds, which contain unfixed type variables.
In this case, we do additional inference of IList<_> and List<int> yielding exact bound int of _.

Type-dependence is required because, till this time when a type variable had any bounds, it didn't contain any unfixed type variable.
It was important because we could do the parameter fixation, where we work with exact types(not unfixed type variables).
However now, the type variable can contain bounds containing unfixed type variables.
We have to ensure that we will not start fixing the type variable till these unfixed type variables are unfixed(In some cases, we can be in a situation, where this dependency will form a cycle. In this case, we will allow the fixation earlier).

Example

We use the previous example.
After the first phase. T1 has bounds IList<_> and List<int>. _ has bound int.
In this situation, we can't start to fix T1 because _ is not fixed yet.
T1 is type-dependent on _.
So, we will first fix _, which becomes int.
Then, T1 is not type-dependent anymore, because all bounds don't contain any unfixed type variables.
IList<_> is now IList<int> after the _ fixation.
We can fix T1 now.

A similar thing is for shape-dependence.
Although it cares about bounds received from the type argument list.
We want a shape bound to be exact (not containing any unfixed type variables) because it is later important for the fixation.
An intention is to keep the exact form of the given hint(IList<_>).

Example

Given IList<_> as a type argument, when we treat nullability, we want the hinted type parameter to be non-nullable(not IList<_>?).
It can happen, other bounds would infer the nullable version, and although IList<_> can be converted to IList<_>?, it is not the user intention.

Part 2

Considering your example

new C<>(42);
class C { ... }
class C<T> { ... }
class C<T1, T2> { ... }

In this case, we forbid(error occurs) it during type lookup because in the scope we don't have a unique class (generic or non-generic) with a typename C.

I made a mistake in my example which should clarify this.
It should be fixed like this.

The ... represents a fragment of code, which would make the code valid(using arguments, the definition of suitable constructors, etc.).
However, the main intention was to clarify typename lookup.
In this case, I can be sure that C1<> refers to C1<T1> because there is no other type with that type name, hence I know the set of constructors to be used in the overload resolution.

class P1
{
   void M() 
   {
       new C1<>(...); // Refers generic_inferred type C1<T>
   }
   class C1<T> {...} 
   class C2<T1, T2> {...}
}

It's true that defined type inference in the standard talks about method type arguments.
I didn't explicitly mention that in the case of type inference for constructors we actually infer type arguments of the type, where constructors are defined.
I will mention it there.

Considering your last note about nested types. new Containing<>.Nested<>(42)
I'm not sure there and I would write it to unresolved questions.
In my opinion, it looks weird and I wouldn't allow it, because then it would be coherent with method type inference and I don't think it would be common usage.
I use nested type as a helper which contains logic of some part of the outside type.
That means it does not usually use all type parameters defined in the outside type.
Hence, there can be a lack of type info to infer type parameters of outside type when we try to use the constructor of nested type.
From the theoretical point of view, it can be done.

I hope that I clarified your questions.
Feel free to ask further.
When I tried to think of the mentioned way how the partial type inference can be done, I found many issues and the resulting solution can be unclear without this insight.
However, I will be glad to explain it when necessary.

What I understood for further changes, I will focus on:

• Fix the example regarding clarification of the typename lookup.
• Highlight sections, which are changed.
• More specify constructing inputs for constructor type inference.
• Mention the actual inferred type parameters in case of type inference for constructor.
• Mention inference of nested type in unresolved questions.
• Add an example explaining reason of type-dependence and shape-dependence similar to the one in this answer.

[TomatorCZ]

Hi,
I made the corrections. It is currently in my repo. I can edit the proposal which in this discussion or create it as a next discussion.

[TomatorCZ]

The proposal continue as a PR here

[julealgon]

Is there a strong reason we are coupling constructor generic type inference, with this much more advanced proposal for partial generic type inference?

It would be super nice if we could decouple those 2 things as work on "standard" generic type inference for constructors could start right away while the more advanced aspects of this proposal here are discussed and defined in more detail.