C# 7.x: in parameter mode

[RexJaeschke]

Almost all the edits support the addition of the in parameter mode.

Support for the v7.2 feature, ref with this (as well as in with this) in an extension method was also added.

Fixes #264
Fixes #296

[RexJaeschke]

@MadsTorgersen, Bill suggested I loop you in on this to see if one aspect of my resolution reflects what is actually going in with the implementation.

Input, output, and reference arguments must be passed to corresponding input, output, and reference parameters, and that's easy to handle. The new possibility, however, involves passing a value argument, which can now match either a value or an input parameter.

In 12.6.4.2, "Applicable function member," I added text to cover the new possibility along with the following example:

public static void M1(int p1) { … }
public static void M1(in int p1) { … }
int i = 10;
M1(i);      // M1(int) and M1(in int) are applicable

Then when calling M1, we have to chose from among these two overloads. To do that, I added a new section, 12.6.4.x, "Better argument-passing mode," which says that the value parameter method wins.

Then, in 12.6.2.3, "Run-time evaluation of argument lists," I added text to cover the value-is-transformed-to-input possibility along with the following example:

public static void M1(in int p1) { … }
int i = 10;
M1(i);         // transformed to a temporary input argument

How does that sound?

[gafter]

Please ensure dotnet/csharplang#945 is reflected in this specification.

[BillWagner]

Please ensure dotnet/csharplang#945 is reflected in this specification.

I believe that rule is covered here: https://github.com/dotnet/csharpstandard/pull/219/files#diff-d9d678d0b42d3c668ebd64159dadfd6188361121feca8fb94fddf8816433cd14R1073-R1085

[BillWagner]

@jskeet This one is now ready for review and merge.

I've rebased, updated all links, and responded to all remaining feedback.

Note for @gafter I believe dotnet/csharplang#945 is incorporated in this spec. The dates of comments and commits make it hard for me to be sure. Can you review?

[jskeet]

Result 2023-04-19: nearly there, but not quite ready for "approve, Bill to fix then merge" - the type inference part probably needs review.

[jskeet]

Action from 2023-04-19: @BillWagner to log the need for a note about odd aliasing later, and assign to @jskeet.

See #782

[KalleOlaviNiemitalo]

If I understand correctly, this PR would require all three calls to choose Fun(in int), but that's not what happens at sharplab.io:

using System;

class C {
    static void Fun(in int i) {
        Console.WriteLine("Fun(in int)");
    }

    static void Fun(long l) {
        Console.WriteLine("Fun(long)");
    }

    static void Main() {
        Fun(1); // calls Fun(in int)

        Fun((dynamic)1); // calls Fun(long)

        Fun(i: (dynamic)1); // RuntimeBinderException
    }
}

[KalleOlaviNiemitalo]

Another variant. Here, I think both calls should go to Fun(ref int, long).

using System;

class C {
    static void Fun(in int i, int j) {
        Console.WriteLine("Fun(in int, int)");
    }

    static void Fun(ref int i, long j) {
        Console.WriteLine("Fun(ref int, long)");
    }

    static void Main() {
        int i = 0;

        Fun(ref i, 0); // calls Fun(ref int, long)
        Fun(ref i, (dynamic)0); // calls Fun(in int, int)
        // Fun(in i, (dynamic)0); // error CS8364
    }
}

It seems to me that this mismatch should be considered a bug in the runtime binder implementation, rather than something to be changed in this PR. Whether the bug will ever be fixed is a different matter.

[jskeet]

I think I may be a bit confused by this in general, but I hope the comments are helpful.

[BillWagner]

If I understand correctly, this PR would require all three calls to choose Fun(in int), but that's not what happens at sharplab.io:

using System;

class C {
    static void Fun(in int i) {
        Console.WriteLine("Fun(in int)");
    }

    static void Fun(long l) {
        Console.WriteLine("Fun(long)");
    }

    static void Main() {
        Fun(1); // calls Fun(in int)

        Fun((dynamic)1); // calls Fun(long)

        Fun(i: (dynamic)1); // RuntimeBinderException
    }
}

Great catch! I added that when an argument is dynamic, there must be an identity conversion to the parameter type if passed as an in parameter.