mcs/docs/ecma334/14.5.5.1.xml

   1 <?xml version="1.0"?>
   2 <clause number="14.5.5.1" title="Method invocations">
   3   <paragraph>For a method invocation, the <non_terminal where="14.5">primary-expression</non_terminal> of the <non_terminal where="14.5.5">invocation-expression</non_terminal> must be a method group. The method group identifies the one method to invoke or the set of overloaded methods from which to choose a specific method to invoke. In the latter case, determination of the specific method to invoke is based on the context provided by the types of the arguments in the <non_terminal where="14.4.1">argument-list</non_terminal>. </paragraph>
   4   <paragraph>The compile-time processing of a method invocation of the form M(A), where M is a method group and A is an optional <non_terminal where="14.4.1">argument-list</non_terminal>, consists of the following steps: <list><list_item> The set of candidate methods for the method invocation is constructed. Starting with the set of methods associated with M, which were found by a previous member lookup (<hyperlink>14.3</hyperlink>), the set is reduced to those methods that are applicable with respect to the argument list A. The set reduction consists of applying the following rules to each method T.N in the set, where T is the type in which the method N is declared: </list_item><list><list_item> If N is not applicable with respect to A (<hyperlink>14.4.2.1</hyperlink>), then N is removed from the set. </list_item><list_item> If N is applicable with respect to A (<hyperlink>14.4.2.1</hyperlink>), then all methods declared in a base type of T are removed from the set. </list_item></list><list_item> If the resulting set of candidate methods is empty, then no applicable methods exist, and a compile-time error occurs. If the candidate methods are not all declared in the same type, the method invocation is ambiguous, and a compile-time error occurs (this latter situation can only occur for an invocation of a method in an interface that has multiple direct base interfaces, as described in <hyperlink>20.2.5</hyperlink>). </list_item><list_item> The best method of the set of candidate methods is identified using the overload resolution rules of <hyperlink>14.4.2</hyperlink>. If a single best method cannot be identified, the method invocation is ambiguous, and a  compile-time error occurs. </list_item><list_item> Given a best method, the invocation of the method is validated in the context of the method group: If the best method is a static method, the method group must have resulted from a <non_terminal where="14.5.2">simple-name</non_terminal> or a  <non_terminal where="14.5.4">member-access</non_terminal> through a type. If the best method is an instance method, the method group must have resulted from a <non_terminal where="14.5.2">simple-name</non_terminal>, a <non_terminal where="14.5.4">member-access</non_terminal> through a variable or value, or a <non_terminal where="14.5.8">base-access</non_terminal>. If neither of these requirements are true, a compile-time error occurs. </list_item></list></paragraph>
   5   <paragraph>Once a method has been selected and validated at compile-time by the above steps, the actual run-time invocation is processed according to the rules of function member invocation described in <hyperlink>14.4.3</hyperlink>. </paragraph>
   6   <paragraph>
   7     <note>[Note: The intuitive effect of the resolution rules described above is as follows: To locate the particular method invoked by a method invocation, start with the type indicated by the method invocation and proceed up the inheritance chain until at least one applicable, accessible, non-override method declaration is found. </note>
   8   </paragraph>
   9   <paragraph>
  10     <note>Then perform overload resolution on the set of applicable, accessible, non-override methods declared in that type and invoke the method thus selected. end note]</note>
  11   </paragraph>
  12 </clause>