`inout` and `auto ref` causing a return value to be accepted by `ref` but not actually be mutated

[jmdavis]

This code

void main()
{
    S foo;
    const S bar;

    functionTakingRef(foo.test);

    assert(foo.test == 69); //fails
    assert(bar.test == 0);
}

void functionTakingRef(ref ubyte u)
{
    u = 69;
}

struct S
{
    private ubyte field;

    auto ref ubyte test() inout
    {
        return field;
    }
}

fails the first assertion. Somehow, test is being called, and its result is being passed to functionTakingRef, and yet that ref isn't being mutated. It's staying 0 like the ref doesn't actually point to field like it's supposed to.

The issue seems to somehow be tied up in auto ref and referring inout in that if test is changed to

    ref inout(ubyte) test() inout

then the code works properly. Curiously,

auto ref inout(ubyte) test() inout

also compiles and works even though both auto ref and ubyte are specified, which also seems like a bug to me, but if so, that's a separate issue.

[pbackus]

There's no bug here. auto ref infers ref if the return value is an lvalue. When the return value has to be implicitly converted from inout(ubyte) to ubyte, it's not an lvalue, because that conversion results in an rvalue.

[jmdavis]

There's no bug here. auto ref infers ref if the return value is an lvalue. When the return value has to be implicitly converted from inout(ubyte) to ubyte, it's not an lvalue, because that conversion results in an rvalue.

I would also expect ref inout(ubyte) to implicitly convert to ref ubyte given that the object is mutable, but maybe the compiler isn't that smart. I don't use inout very often, so I don't know how good a job it does with that sort of thing in practice.

Regardless, either the return type is compatible with ref ubyte, and the mutation should succeed, or the return type is not compatible, and there should be a compilation error when passing the return value to functionTakingRef, because it requires ref ubyte. So, I don't see how it could be anything other than a bug.

[pbackus]

I would also expect ref inout(ubyte) to implicitly convert to ref ubyte given that the object is mutable, but maybe the compiler isn't that smart.

If the return type is inout(ubyte), it is substituted at the call site for ubtyte/const ubyte/immutable ubyte, and it works like you describe. If the return type is just ubyte, you force the conversion to happen regardless of what object it's called with. So, even if you call it with a const object, it still has to return a mutable ubyte. That requires a copy.

there should be a compilation error when passing the return value to functionTakingRef

Good point; that is indeed a bug. Probably the same one I reported in #19893.

[jmdavis]

I would also expect ref inout(ubyte) to implicitly convert to ref ubyte given that the object is mutable, but maybe the compiler isn't that smart.

If the return type is inout(ubyte), it is substituted at the call site for ubtyte/const ubyte/immutable ubyte, and it works like you describe. If the return type is just ubyte, you force the conversion to happen regardless of what object it's called with. So, even if you call it with a const object, it still has to return a mutable ubyte. That requires a copy.

Ah, true. The return type isn't auto ref, it's auto ref ubyte. So, you don't get inout. If it were just auto ref, then maybe it would be different.

there should be a compilation error when passing the return value to functionTakingRef

Good point; that is indeed a bug. Probably the same one I reported in #19893.

Yeah, that looks like it's the same issue. I didn't find it before, because I was searching for bugs with inout.