[RexJaeschke]

This is Rex's adaptation of the corresponding MS proposal.

Notes

1. The proposal section “Better function member” contains 3 pages of rationale, none of which are included in this PR.
2. As dynamic binding is implementation-defined, the proposal section “Dynamic Binding” is not included in this PR.
3. 12.6.2.3 Run-time evaluation of argument lists states, “The expressions of an argument list are always evaluated in textual order.” The proposal section “Order of evaluation with non-array collections in non-trivial scenarios” contains 4 pages of examples, none of which are included in this PR. However, it might be necessary to say something, as it appears the behavior with params non-array collection differs from that of a params array.
4. The proposal section “Ref safety” states, “Params parameters are implicitly scoped when their type is a ref struct. UnscopedRefAttribute can be used to override that.” Presumably that was added to the spec when support for scoped was added in V11, and nothing specific to parameter collections need be added in V13. See the proposal section “Open questions/[Resolved] Implicitly scoped params” and section “Open questions/[Resolved] Consider enforcing scoped or params across overrides,” neither of which has resulted in text in this PR.
5. The proposal section “Open questions/ [Resolved] Should presence of required members prevent declaration of params parameter?” has a recommendation. However, I did not add any text re that in this PR.
6. The spec in “Better function member” contains the following text, which is not mentioned in the MS proposal rewrite of this subclause; should this text be retained or removed?

• for each argument, the implicit conversion from Eᵥ to Pᵥ is not an anonymous function type conversion, and

• Mᵥ is a non-generic method or Mᵥ is a generic method with type parameters {X₁, X₂, ..., Xᵥ} and for each type parameter the type argument is inferred from an expression or from a type other than an anonymous function type, and

• for at least one argument, the implicit conversion from Eᵥ to Qᵥ is an anonymous function type conversion, or Mₓ is a generic method with type parameters {Y₁, Y₂, ..., Yᵥ} and for at least one type parameter the type argument is inferred from an anonymous function type, or[