Champion: ref local reassignment (15.7)

[gafter]

The span safety rules at https://github.com/dotnet/csharplang/blob/master/proposals/csharp-7.2/span-safety.md describe rules that would make it safe to reassign ref locals (and ref parameters), presumably with some syntax similar to variable = ref somelvalue. I propose we add support for this.

As part of this, we'd also allow iteration variables to be ref in for and foreach loops (as initially tracked by #1046).

• Proposal added (https://github.com/dotnet/csharplang/blob/master/proposals/csharp-7.3/ref-local-reassignment.md)
• Discussed in LDM (2017-10-02)
• Decision in LDM
• Finalized (done, rejected, inactive)
• Spec'ed

LDM
https://github.com/dotnet/csharplang/blob/master/meetings/2017/LDM-2017-10-02.md

---

This was discussed in the 2017-09-02 LDM meeting, with the following tentative directions:

• We will try to get ref reassignment into release 7.2 (update: we didn't manage to get this into 7.2, so it is now a 7.3 candidate)
• The syntax for ref reassignment is e1 = ref e2. In other words, there is a single ref keyword and it appears after the = operator.
• This is an expression form. It yields an lvalue.
• Ref parameters may be ref-reassigned.

We do not expect to support "uninitialized" ref variables at this time. That is a possible future direction. We think it is a straightforward and simple extension, and we anticipate doing it sooner rather than later. If it turns out to be easy, it is possible it would make 7.2.

---

This was further discussed in the 2017-10-25 LDM meeting, where it was requested that the following be added to the scope of this championed issue for tentative work in C# 7.3:

• Add support for declaring uninitialized ref locals, which includes defining their escape scope and some appropriate definite assignment treatment.
• Add support for (Proposal: Allow iteration variables to be ref in for and foreach loops #1046) declaring for and foreach iteration variables as ref, giving them some appropriate semantics.

[benaadams]

Thank you :)

Aside

Not having separated declare and init would convolute some code e.g.

ref int value;
for (int i = 0; i < arr.Length; i++)
{
    ref value = arr[i];
}
// Though what would ref value be if arr.Length == 0?

However, can be worked around with the ternary operator (choice on condition) or initializing first item outside loop (in above example) - so isn't as important to address.

Though nullable ref may also be option to consider

ref? int TryGetLastIneffienctly()
{
    ref? int value = null;
    for (int i = 0; i < _arr.Length; i++)
    {
        if (i == _arr.Length - 1)
        {
            ref value = ref _arr[i];
        }
    }

    return ref value;
)

Which also resolves the current need to have a static placeholder ref

static int s_NotFound;

ref int TryGetLastIneffienctly(bool out success)
{
    for (int i = 0; i < _arr.Length; i++)
    {
        if (i == _arr.Length - 1)
        {
            success = true;
            return ref value = ref _arr[i];
        }
    }
    
    success = false;
    return ref s_NotFound
)

[gafter]

I don't think we can solve the problems arising from null by introducing new kinds of null.

[benaadams]

Fair enough :)

[ygc369]

good idea

[Thaina]

@gafter @benaadams I was propose #521

[gafter]

This was discussed in the 2017-10-02 LDM meeting, with the following tentative directions:

• We will try to get ref reassignment into release 7.2
• The syntax for ref reassignment is e1 = ref e2. In other words, there is a single ref keyword and it appears after the = operator.
• This is an expression form. It yields an lvalue.
• Ref parameters may be ref-reassigned.

We do not expect to support "uninitialized" ref variables at this time. That is a possible future direction. We think it is a straightforward and simple extension, and we anticipate doing it sooner rather than later. If it turns out to be easy, it is possible it would make 7.2.

[gafter]

A tentative spec for ref local reassignment is here: #963