C# 7.x ref assignment to input parameter

[KalleOlaviNiemitalo]

Describe the bug

In the C# 7.x draft, 12.21.3 could be a bit clearer about input parameters here:

If the left operand is a writeable ref (i.e., it designates anything other than a ref readonly local or in parameter), then the right operand shall be a writeable variable_reference. If the right operand variable is writeable, the left operand may be declared ref or ref readonly.

Example

This should be valid.

class C {
    int j;
    void M(in int i) {
        i = ref j;
    }
}

Expected behavior

Say that the left operand may be declared in as an input parameter.

Additional context

Poking this, I met the ref-safe-to-escape rules

class C {
    ref readonly int M(in int i, int j) {
        ////i = ref j; // error CS8374
        return ref i;
    }
}

The ref assignment here looks benign on its own, but it must be rejected because the method could then return that ref. I have not checked whether the draft specifies an error here.

[jskeet]

At the start of 12.21.3 we already have:

The left operand shall be an expression that binds to a reference variable (§9.7), a reference parameter (other than this), an output parameter, or an input parameter.

The bit you've quoted is only meant to be restricting what's used for the right operand, e.g. to prevent:

static void M(in int i)
{
    ref int j = ref i;
}

For the second part, the error occurs even without return ref (even in a void method) I believe it's prohibited already:

12.21.3: "It is a compile time error if the ref-safe-context (§9.7.2) of the left operand is wider than the ref-safe-context of the right operand."

9.7.2.2: "If p is a ref, or in parameter, its ref-safe-context is the caller-context. If p is an in parameter, it can’t be returned as a writable ref but can be returned as ref readonly." (So the ref-safe-context of i is caller-context.)

9.7.2.2: (After things that don't apply to j) "Otherwise, the parameter is a value parameter, and its ref-safe-context is the function-member." So the ref-safe-context of j is function-member.

caller-context is wider than function-member, so it's prohibited.

Proposal for the meeting: check my logic, then close the issue without further spec changes.

[KalleOlaviNiemitalo]

So you're saying that this

If the right operand variable is writeable, the left operand may be declared ref or ref readonly.

is not meant to disallow other ways of declaring the left operand.

[jskeet]

So you're saying that this

If the right operand variable is writeable, the left operand may be declared ref or ref readonly.

is not meant to disallow other ways of declaring the left operand.

Correct. If it required the left operand to be declared ref or ref readonly then it would be "shall" rather than "may".

[Nigel-Ecma]

I think we can improve this a little, I'll put out a PR…

[Nigel-Ecma]

@KalleOlaviNiemitalo, @jskeet – see PR #917. I think that addresses it, I think it was a “typo”

[KalleOlaviNiemitalo]

The distinction between read-only and writable refs, or more generally variable_references, still seems inadequately specified but I guess it's better to fix that as part of #894.

[jskeet]

@KalleOlaviNiemitalo: So just to check we're on the same page, are you happy for us to merge #917 and then take a bigger swing at read-only/writable refs in a separate PR to address #894?

[KalleOlaviNiemitalo]

Yes that's fine.

[BillWagner]

Notes for 9/6 meeting:

I read through the comments, and #917. I agree that this can be closed without further action.

[jskeet]

Closing.