Return ref readonly and ternary operator - why require an extra ref?

[qrli]

I wrote several times without success. So I wrote if-else and let auto-fix to rewrite it. The result syntax is surprising to me.
Why the ref after return? The ternary operator is already returning ref. Doesn't it mean ref ref in this case?

        public static ref readonly StreamEntryId Min(in StreamEntryId id1, in StreamEntryId id2)
        {
            ...
            return ref (id1.sequenceNumber <= id2.sequenceNumber ? ref id1 : ref id2);
            ...
        }

[HaloFour]

The ref within the ternary expression only specifies that the type of that expression is ref StreamEntryId, but you still need return ref to explicitly return by ref. IIRC this is true in all cases of when you return by ref, even if what you're returning is already a ref.

public ref int M(ref int x) {
    ref int y = ref x;
    return ref y;
}

[qrli]

In your example, when y is used instead of ref y, it clearly means the value of y. So return y is obviously wrong, while return ref y makes sense.

On the other hand, ref y is the ref of y, which has the same type as the result of ternary operator. Then by your logic, it should require us to write return ref (ref y), or it should be legal to write like that. So I still do not get it.

[En3Tho]

Afaik dereference rules are kicking it and whenever possible compiler will try to dereference a ref to actual value. So return y where y is ref int still means return the actual value of y, not the address. So you have to add "ref" manually to compensate for these dereference rules.

While I see that this is sorta confusing, especially when refs of refs are involved but if you accept/keep in mind the auto dereferencing then it's sorta easier.

[qrli]

@En3Tho Thanks for answering, but that's not answer my question. I understand how it work. My question is really about why adding ref when expression is already ref, which implies return ref (ref y) which is obviously wrong.

[kyoyama-kazusa]

The first ref keyword presents a "ref environment" to allow using ref expression, and the following ref expression is used for modifying the expression or variable, indicating it returns a reference instead of a normal variable value.

For the first ref keyword, it is used as a normal ref-returning expression such as:

// here        here
//  ↓           ↓
   ref int a = ref expression;

or

// here
//   ↓
    ref int Method()
    {
//            here
//              ↓
        return ref ...;
    }

We should use a pair of ref keywords.

For the last two ref keywords, they are only used for modifying the variable after ? and : token, indicating they are reference here.

If the ternary ref-returning expression is used as an lvalue, the first ref can be omitted:

// No ref keyword
//     |        requires ref
//     |             |  requires ref
//     ↓             ↓       ↓
       (condition ? ref a : ref b) = ...;

Here a and b still require ref modifier because a and b now is used for assigned a value. This usage is just like a normal ref-returning expression as an lvalue:

// No ref keyword
//    ↓
      F() |= 42;
// Equivalent to
//ref int i = ref F();
//i |= 42;

ref int F()
{
    return ref ...;
}

[qrli]

The first ref keyword presents a "ref environment" to allow using ref expression

That means return ref (ref y); should be legal and how it suppose to work. But it is not.
I tried some other expression:

ref int Bar(in int v) => ref v;

ref readonly int Foo(in int a, in int b)
{
    return ref Bar(a); // must add `ref` here
}

int v = 10;
int w = 1;
ref int x = ref v switch {
        10 => ref Bar(v),  // error CS1073: Unexpected token 'ref'
        _ => ref Foo(1, 2) // error CS1073: Unexpected token 'ref'
        };
ref int y = ref ((v > 0) ? ref v : ref w); // OK
ref int z = ref ((v > 0) ? ref Bar(v) : ref Foo(1, 2)); //error CS1510: A ref or out value must be an assignable variable

It does not seem to be consistent...

[qrli]

After playing around, I got it mostly compiling, except switch expression:

ref int Bar(ref int v) => ref v;

ref readonly int Foo(in int a, in int b)
{
    return ref a;
}

int v = 10;
int w = 1;
ref readonly int x = ref v switch {
        10 => ref Bar(ref v),  // error CS1073: Unexpected token 'ref'
        _ => ref Foo(1, 2) // error CS1073: Unexpected token 'ref'
        };
ref readonly int y = ref ((v > 0) ? ref v : ref w);
ref readonly int z = ref ((v > 0) ? ref Bar(ref v) : ref Foo(1, 2));

[333fred]

Ref switch is not currently a feature: #3326.

[HaloFour]

Seems it's explained here: https://github.com/dotnet/csharplang/blob/main/proposals/csharp-7.2/conditional-ref.md

Ref ternary is an LValue and as such it can be passed/assigned/returned by reference;
...
Ref ternary can be used in a regular (not ref) context as well. Although it would not be common since you could as well just use a regular ternary.

[qrli]

So, for int y, the expression ref y is not really of ref int type, but just an lvalue of type int... That explains it.

[qrli]

But still, why return ref (ref y) is an error? (ref y) is an lvalue expresion too.

[tfenise]

(ref y) does not seem to be an LValue.

int x = 1;
int y = 2;
(ref x) = 3;//does not compile
(x > y ? ref x : ref y) = 4;//do compile

So basically as I understand, someBool ? someRef1 : someRef2 takes two "ref type" expressions someRef1 and someRef2, and gives an LValue expression, but not a "ref type" expression as its parameters someRef1 and someRef2.

[qrli]

Yes.
It is a bit counter-intuitive, but also a good thing that return ref (ref y); is not legal. Just that there is no easy way to explain it.