Proposal: allow contravariant out parameters

[YairHalberstadt]

Given types A and B where A : B
I suggest the following code should be valid

// Declare a method using an A out parameter
public static Method(out A a) => new a();

...

// Call the method with a B
Method(out B b);

//This should be compiled to
Method(out A temp);
B b = temp;

A use of this might be passing an IReadOnlyList as an out parameter to something which accepts a List.

[HaloFour]

Are you suggesting this for both regular out parameters and out declarations?

// given
void Method(out List<string> l) {
    l = new List<string>();
}

// regular out parameter
IReadOnlyList<string> l1;
Method(out l1);

// out declaration
Method(out IReadOnlyList<string> l2);

[YairHalberstadt]

Yes, by creating a temporary variable of the correct type

…

On Wed, 1 Aug 2018, 21:16 HaloFour, ***@***.***> wrote: Are you suggesting this for both regular out parameters and out declarations? // givenvoid Method(out List<string> l) { l = new List<string>(); } // regular out parameterIReadOnlyList<string> l1;Method(out l1); // out declarationMethod(out IReadOnlyList<string> l2); — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/dotnet/csharplang/issues/1760#issuecomment-409707372>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Ab0rANi4HlF5aCqXIvEP3lqlOTpOIbGZks5uMgyBgaJpZM4Vq_Ax> .

[HaloFour]

That would change the behavior of out parameters in subtle ways. When the callee assigns the out/ref parameter the target of that reference is immediately assigned, which is observable. With a temporary variable the target can't be assigned until after the callee returns.

For example:

public class Foo {
    private IReadOnlyList<string> r;
    private List<string> l;

    public void M(out List<string> list) {
        list = new List<string>();
        throw new Exception("oops!");
    }

    public void Test1() {
        try {
            M(out l);
        }
        catch { }
        Debug.Assert(l != null); // succeeds
    }

    public void Test2() {
        try {
            M(out r);
        }
        catch { }
        Debug.Assert(r != null); // fails
    }
}

[Joe4evr]

Test2 doesn't even compile, according to SharpLab.

[HaloFour]

@Joe4evr

Not today. This proposal would seek to change that.

[YairHalberstadt]

@HaloFour

I presume the original semantics could be preserved by the compiler wrapping it in a try finally block.

So given your example

public class Foo {
    private IReadOnlyList<string> r;
    private List<string> l;

    public void M(out List<string> list) {
        list = new List<string>();
        throw new Exception("oops!");
    }

    public void Test1() {
        try {
            M(out l);
        }
        catch { }
        Debug.Assert(l != null); // succeeds
    }

    public void Test2() {
        try {
            M(out r);
            /* This compiles down to
            try { M(out var temp); }
            finally { r = temp; } */
        }
        catch { }
        Debug.Assert(r != null); // succeeds
    }
}

[HaloFour]

@YairHalberstadt

That's only one of the scenarios in which it's observable. Here is another:

public class C {
    private IReadOnlyList<string> r;

    public void M(out List<string> list) {
        list = new List<string>();
        M2();
    }

    public void M2() {
        Debug.Assert(list != null);
    }

    public void Test() {
        M(out r);
    }
}

These may be minor points. But at the same time the amount of syntax to workaround this intentional limitation is not onerous.

[ufcpp]

#317 (comment)

[YairHalberstadt]

@HaloFour
I Agree. I don't think I appreciated the shear complexity even such a minor addition throws up.

[YairHalberstadt]

Still I think I'll leave this open in case someone comes up with a better way of achieving something similar?

[HaloFour]

Sure. I'm not necessarily arguing against the idea, just noting that it would behave differently. The same would be true if C# were to move to support ref/out properties. The compiler would have to emit IL to invoke the property setter after the method returned (probably in a finally block) so the change to the reference wouldn't be immediately available. But I think it's a good idea to at least get all of these little details on the table so that they can be discussed accordingly.

[jnm2]

I want this outcome regardless of the method used to achieve it.

To be fair, if your program depends on an out parameter being observable before the method returns, you probably have bigger issues. :D