Allow forwarding ref readonly arguments using ref or ref readonly

[sweemer]

It seems odd to me that ref readonly function arguments can only be passed to another function taking a ref readonly argument by using in instead of ref or ref readonly.

• Allowing ref at the call site would be more consistent with the syntax for forwarding non-readonly arguments, assuming that the compiler can propagate the readonly-ness.
• Allowing ref readonly at the call site would be more consistent with the function argument modifiers.

I tried searching for the reason why in was chosen for this scenario but couldn't find it. Is it too late to consider allowing either ref or ref readonly as well?

public readonly struct S
{
    public readonly int i;
}

public class C
{
    private void F1(ref readonly S s) { }
    private void F2(ref S s) => F1(ref s); // OK
    private void F3(ref readonly S s) => F1(in s); // OK
    private void F4(ref readonly S s) => F1(ref s); // CS8329
    private void F5(ref readonly S s) => F1(ref readonly s); // CS1525
}

[En3Tho]

Well, as you know "in" is an existing keyword that represents an "inref" - a kind of byref argument that doesn't allow mutation of ref's content. You declare an "in" parameter and pass a value via using an explicit "in" or an implicit one.

Now the provlem with "in" arguments is that it doesn't require caller to assign a storage for the argument. E.g. you can easily pass literals to "in" for example.

"ref readonly" is conceptually similar to "in" - a reference content of which can't be mutated. But the important difference is that it requires caller to first assign a storage (a variable, heap/stack memory).

So "in" was a natural choice because it clearly indicates a readonly behavior. It's just that "ref readonly" is a stricter version.

[sweemer]

@En3Tho I understand everything you wrote, and agree that in is a natural choice, but my question is whether it should be the only choice. It seems to me that allowing ref readonly in addition to in when forwarding arguments would provide consistency of modifiers without any loss of functionality, which would be a good thing.