[c# 7.3] cannot pass this with in? Seems like you should

[gafter]

@Thraka commented on Tue Jan 08 2019

Version Used: 7.3

Steps to Reproduce:

1. Use the code below

class A
{
    public string Name;
    public void MapObjectB(in B obj) { }
}

class B
{
    public string Name;
    public void DoWorkWithA(A obj) => obj.MapObjectB(in this);
}

class Program
{
    void Main()
    {
        var a = new A();
        var b = new B();
        a.Name = "Bob";
        b.DoWorkWithA(a);
    }
}

Expected Behavior:

I could use in this as this is passed with in, it is read-only and not assignable.

Actual Behavior:

Error that you cannot pass this by ref

---

@gafter commented on Tue Jan 08 2019

The compiler is correct. this is a value, not a variable. Nevertheless, this is a reasonable feature request so I'm moving it to csharplang.

[svick]

The code obj.MapObjectB(this); compiles (because the in modifier is usually optional). Isn't that sufficient?

[Thraka]

Yes, it will compile if you remove in. Does it do anything different? From what I remember reading about in, removing it from the calling code made the compiler optimize one way and having there did some sort of other optimization?

Either way, being able to put in this at least shows intent to use this as readonly. Although this is always readonly.. i donno if it makes sense to have it or not. I just wanted to bring it up because it seemed like it should work. 😄

[Joe4evr]

Yes, it will compile if you remove in. Does it do anything different? From what I remember reading about in, removing it from the calling code made the compiler optimize one way and having there did some sort of other optimization?

No, because either way the variable is passed by ref (since that's how the method is declared). I was very much against the case of in becoming implicit, as it obfuscates what is happening at the call-site.

Also, passing by in for reference types doesn't make a ton of sense in the first place. If you remove in entirely, the net effect is identical:

public void MapObjectB(B obj)
{
    obj = new B(); //doesn't replace the instance that was passed at the call-site
}

Moreover, using in outside of its intended place (being large value types) actually generates a lot more overhead, often leading to worse performance, and in the worst case corrupting your memory.

[Thraka]

My purpose for putting in in there was to demonstrate intent. "Hey I know you're passing me that object, I'm telling you I'm using it in a read-only fashion."

[tannergooding]

Hey I know you're passing me that object, I'm telling you I'm using it in a read-only fashion

It doesn't mean that you are using it a readonly fashion however. You end up with a double indirection (effectively a T**) where the T* can't be changed, but the underlying T still can.

This is in contrast to a value type passed by in, where you end up with a single indirection (effectively a T*) where the underlying T can't be changed.

[Neme12]

Why would you use in with a reference type?

[Thraka]

I was playing around and trying to communicate the intent of "i'm treating what you pass me as readonly". I just thought I would raise this issue as it felt odd to me. We can just close it as it seems it's not really a big deal nor really a bug.