`readonly ref` and `in` parameters removes warning CS0649: Field 'field' was never assigned to.

[itsBuggingMe]

Version Used:
Not sure - I found the error while using sharplab.

Steps to Reproduce:

1. Create a private unused field in a class or struct.
2. Pass the private field as ref readonly or in into a method.

Repro (edited)

Diagnostic Id:

CS0649: Field 'field' is never assigned to, and will always have its default value 'value'.

Expected Behavior:

The warning still persists, even when the field is passed by a readonly reference into a method.

Actual Behavior:

Warning is removed.

[jaredpar]

The warning still persists, even when the field is passed by a readonly reference into a method.

That is expected though because ref readonly disallows modification of the value. Hence there is no way for the Consume2 method to write to the ref x value.

I looked at the provided sharplab repro and everything is behaving as I would expect. Why do you think Consume2(ref x) should remove the warning? Or is there a diff combo that you think should remove the warning that isn't?

[itsBuggingMe]

Shoot - I messed up the Sharplab repro. The call should have been Consume3(in x); not Consume3(x);.

The Consume3(in x); does not have a warning, while Consume3(x); does, even though the semantics are the same.

My concern is that the warning is being removed, when it should not be. Since an in or a ref readonly cannot be modified, the field is still unused and still "never assigned to".

[jaredpar]

The Consume3(in x); does not have a warning, while Consume3(x); does, even though the semantics are the same.

Ah okay. Yeah that is mostly likely just an oversight when we initially did the in work. It was very ref-like and we likely just missed that particular case.

@jjonescz did you come across this when doing the ref readonly work?

[jjonescz]

The Consume3(in x); does not have a warning, while Consume3(x); does, even though the semantics are the same.

Looks like you are on some old compiler version, recent versions have warning in both cases. SharpLab's main seems to be broken, but you can see that here.

[jjonescz]

However, while playing with your example I noticed that the following doesn't produce a warning and that seems unexpected. I think that's an oversight from the ref readonly feature, because that allowed ref on the call site to be used for readonly references.

public class C
{
    private int x;
    
    public void M()
    {
        Consume(ref x);
    }
    
    private static void Consume(ref readonly int x) { } // `in` has the same unexpected behavior
}

[jaredpar]

Agree, that should also warn. It does mean that changing ref to ref readonly on a parameter can be a breaking change, albeit a pretty narrow one. But don' think that should block us fixing that.