Run-time evaluation of argument lists

During the run-time processing of a function member invocation (§7.5.4), the expressions or variable references of an argument list are evaluated in order, from left to right, as follows:

· For a value parameter, the argument expression is evaluated and an implicit conversion (§6.1) to the corresponding parameter type is performed. The resulting value becomes the initial value of the value parameter in the function member invocation.

· For a reference or output parameter, the variable reference is evaluated and the resulting storage location becomes the storage location represented by the parameter in the function member invocation. If the variable reference given as a reference or output parameter is an array element of a reference-type, a run-time check is performed to ensure that the element type of the array is identical to the type of the parameter. If this check fails, a System.ArrayTypeMismatchException is thrown.

Methods, indexers, and instance constructors may declare their right-most parameter to be a parameter array (§10.6.1.4). Such function members are invoked either in their normal form or in their expanded form depending on which is applicable (§7.5.3.1):

· When a function member with a parameter array is invoked in its normal form, the argument given for the parameter array must be a single expression that is implicitly convertible (§6.1) to the parameter array type. In this case, the parameter array acts precisely like a value parameter.

· When a function member with a parameter array is invoked in its expanded form, the invocation must specify zero or more positional arguments for the parameter array, where each argument is an expression that is implicitly convertible (§6.1) to the element type of the parameter array. In this case, the invocation creates an instance of the parameter array type with a length corresponding to the number of arguments, initializes the elements of the array instance with the given argument values, and uses the newly created array instance as the actual argument.

The expressions of an argument list are always evaluated in the order they are written. Thus, the example

class Test
{
static void F(int x, int y = -1, int z = -2) {
System.Console.WriteLine("x = {0}, y = {1}, z = {2}", x, y, z);
}

static void Main() {
int i = 0;
F(i++, i++, i++);
F(z: i++, x: i++);
}
}

produces the output

x = 0, y = 1, z = 2
x = 4, y = -1, z = 3

The array co-variance rules (§12.5) permit a value of an array type A[] to be a reference to an instance of an array type B[], provided an implicit reference conversion exists from B to A. Because of these rules, when an array element of a reference-type is passed as a reference or output parameter, a run-time check is required to ensure that the actual element type of the array is identical to that of the parameter. In the example

class Test
{
static void F(ref object x) {...}

static void Main() {
object[] a = new object[10];
object[] b = new string[10];
F(ref a[0]); // Ok
F(ref b[1]); // ArrayTypeMismatchException
}
}

the second invocation of F causes a System.ArrayTypeMismatchException to be thrown because the actual element type of b is string and not object.

When a function member with a parameter array is invoked in its expanded form, the invocation is processed exactly as if an array creation expression with an array initializer (§7.6.10.4) was inserted around the expanded parameters. For example, given the declaration

void F(int x, int y, params object[] args);

the following invocations of the expanded form of the method

F(10, 20);
F(10, 20, 30, 40);
F(10, 20, 1, "hello", 3.0);

correspond exactly to

F(10, 20, new object[] {});
F(10, 20, new object[] {30, 40});
F(10, 20, new object[] {1, "hello", 3.0});

In particular, note that an empty array is created when there are zero arguments given for the parameter array.

When arguments are omitted from a function member with corresponding optional parameters, the default arguments of the function member declaration are implicitly passed. Because these are always constant, their evaluation will not impact the evaluation order of the remaining arguments.

Type inference

When a generic method is called without specifying type arguments, a type inference process attempts to infer type arguments for the call. The presence of type inference allows a more convenient syntax to be used for calling a generic method, and allows the programmer to avoid specifying redundant type information. For example, given the method declaration:

class Chooser
{
static Random rand = new Random();

public static T Choose<T>(T first, T second) {
return (rand.Next(2) == 0)? first: second;
}
}

it is possible to invoke the Choose method without explicitly specifying a type argument:

int i = Chooser.Choose(5, 213); // Calls Choose<int>

string s = Chooser.Choose("foo", "bar"); // Calls Choose<string>

Through type inference, the type arguments int and string are determined from the arguments to the method.

Type inference occurs as part of the binding-time processing of a method invocation (§7.6.5.1) and takes place before the overload resolution step of the invocation. When a particular method group is specified in a method invocation, and no type arguments are specified as part of the method invocation, type inference is applied to each generic method in the method group. If type inference succeeds, then the inferred type arguments are used to determine the types of arguments for subsequent overload resolution. If overload resolution chooses a generic method as the one to invoke, then the inferred type arguments are used as the actual type arguments for the invocation. If type inference for a particular method fails, that method does not participate in overload resolution. The failure of type inference, in and of itself, does not cause a binding-time error. However, it often leads to a binding-time error when overload resolution then fails to find any applicable methods.

If the supplied number of arguments is different than the number of parameters in the method, then inference immediately fails. Otherwise, assume that the generic method has the following signature:

T_r M<X₁…X_n>(T₁ x₁ … T_m x_m)

With a method call of the form M(E₁ …E_m) the task of type inference is to find unique type arguments S₁…S_n for each of the type parameters X₁…X_n so that the call M<S₁…S_n>(E₁…E_m)becomes valid.

During the process of inference each type parameter X_i is either fixed to a particular type S_i or unfixed with an associated set of bounds. Each of the bounds is some type T. Initially each type variable X_i is unfixed with an empty set of bounds.

Type inference takes place in phases. Each phase will try to infer type arguments for more type variables based on the findings of the previous phase. The first phase makes some initial inferences of bounds, whereas the second phase fixes type variables to specific types and infers further bounds. The second phase may have to be repeated a number of times.

Note: Type inference takes place not only when a generic method is called. Type inference for conversion of method groups is described in §7.5.2.13 and finding the best common type of a set of expressions is described in §7.5.2.14.

The first phase

For each of the method arguments E_i:

• If E_i is an anonymous function, an explicit parameter type inference (§7.5.2.7) is made from E_i to T_i
• Otherwise, if E_i has a type U and x_i is a value parameter then a lower-bound inference is made from U to T_i.
• Otherwise, if E_i has a type U and x_i is a ref or out parameter then an exact inference is made from U to T_i.
• Otherwise, no inference is made for this argument.

The second phase

The second phase proceeds as follows:

• All unfixed type variables X_i which do not depend on (§7.5.2.5) any X_j are fixed (§7.5.2.10).
• If no such type variables exist, all unfixed type variables X_i are fixed for which all of the following hold:
• There is at least one type variable X_j that depends on X_i
• X_i has a non-empty set of bounds
• If no such type variables exist and there are still unfixed type variables, type inference fails.
• Otherwise, if no further unfixed type variables exist, type inference succeeds.
• Otherwise, for all arguments E_i with corresponding parameter type T_i where the output types (§7.5.2.4) contain unfixed type variables X_j but the input types (§7.5.2.3) do not, an output type inference (§7.5.2.6) is made from E_i to T_i. Then the second phase is repeated.

Input types

If E is a method group or implicitly typed anonymous function and T is a delegate type or expression tree type then all the parameter types of T are input types of E with type T.

Output types

If E is a method group or an anonymous function and T is a delegate type or expression tree type then the return type of T is an output type of E with type T.

Dependence

An unfixed type variable X_i depends directly on an unfixed type variable X_j if for some argument E_k with type T_k X_j occurs in an input type of E_k with type T_k and X_i occurs in an output type of E_k with type T_k.

X_j depends on X_i if X_j depends directly on X_i or if X_i depends directly on X_k and X_k depends on X_j. Thus “ depends on ” is the transitive but not reflexive closure of “ depends directly on ”.

Output type inferences

An output type inference is made from an expression E to a type T in the following way:

· If E is an anonymous function with inferred return type U (§7.5.2.12) and T is a delegate type or expression tree type with return type T_b, then a lower-bound inference (§7.5.2.9) is made from U to T_b.

· Otherwise, if E is a method group and T is a delegate type or expression tree type with parameter types T₁…T_k and return type T_b, and overload resolution of E with the types T₁…T_k yields a single method with return type U, then a lower-bound inference is made from U to T_b.

· Otherwise, if E is an expression with type U, then a lower-bound inference is made from U to T.

· Otherwise, no inferences are made.