[Proposal] Allow readonly reference (in) when unboxing

[IS4Code]

Currently, the result of an unboxing conversion is a value, not a variable. Consequently, when an attempt is made to obtain the reference to the result, an error is generated. However, the error message suggests an in reference might work. It doesn't:

static void Method(in int arg)
{
}

object boxed = 0;
Method(in (int)boxed); // CS0445: Cannot modify the result of an unboxing conversion

The error message is factually incorrect, as a readonly reference (in) cannot be used to modify the value of the object, and so no modification happens and no modification could ever happen (as far as C# is concerned).

I think that, in the spirit of improving performance considering value types, being able to directly access the value of the object without having to copy it would be beneficial. Moreover, unbox.any already provides a reference (which is stated to be read-only in the specification), so in fits that well.

Moreover, copying the value in some additional cases is also unnecessary. Currently, calling a method on a readonly struct copies the value even though no modifications are guaranteed (but obtaining the value of a field doesn't copy the whole struct), and in the future, calling a readonly method (per this proposal) also seems to be plausible without copying.

[YairHalberstadt]

I think the error message is definitely confusing. It's probably worth opening an issue on Roslyn to fix it. You could even fix it yourself - it's extremely easy to do.

As for allowing this: in parameters are kind of niche, and is it really worth changing the language for such an edge case when a workaround is so simple? Remember that every language feature starts at -100 points.

[IS4Code]

@YairHalberstadt You are generally correct, but I'd view this more like leveraging certain restrictions rather than adding a brand new feature. It's obvious this feature was added back when readonly references weren't possible (as the message suggests), but now that they're here, this seems natural to follow.

Just for information, what is the workaround for getting the reference without copying?

As for its use, let's say you have an object (perhaps obtained via reflection) that stores a large structure, or perhaps the structure isn't so large but the unboxing happens many times. It's possible in some cases there is a better solution (like not using a struct), but I can imagine sometimes there isn't much to do.

[YairHalberstadt]

@IllidanS4
I'm afraid the work is much the same either way :-).

[canton7]

The workaround is to make your struct implement an interface, then cast the box to the interface type.

Looks like you might be able to use Unsafe.Unbox as well? SharpLab doesn't allow it and I'm on mobile, so can't test.

[john-h-k]

yeah at the moment do
Method(in Unsafe.Unbox<int>(obj))