Why class passed by in are mutable?

[JStepien90]

I have a question related to this feature. Why structs pass to the function using in keyword are immutable when classes are mutable? I'm asking because in my opinion this behaviour introduces unnecessary confusion. I think all types pass by in should be immutable. Could someone explain me why this works in this way right now?

[CyrusNajmabadi]

Why structs pass to the function using in keyword are immutable when classes are mutable?

What is an immutable class? :)

How would the compiler enforce immutability?

[CyrusNajmabadi]

Note: structs passed to a function using 'in' are effectively immutable. That's because any mutation that might happen (for example, calling an instance method), happens on a defensive copy of that struct. This is how immutability can be achieved. As far as the caller is concerned, the value can't ever change.

No such thing is possible with classes. There is no way to do a 'defensive copy' to give a copy of the value to operate on. And, if anything that could cause mutation were disallowed on classes, then you would literally be unable to use them at all (except to access fields off of them).

[JStepien90]

I’m talking about simple situation when we have a public property e.g Name. When struct with that property is passed to the function via in keyword there is no possibility to change this property. In situation when class is passed in the same manner - this property could be changed without problem. What do you mean saying defensive copy? I thought that in params are passed by reference? Do not have I right?

[CyrusNajmabadi]

What do you mean saying defensive copy? I thought that in params are passed by reference? Do not have I right?

'in' params are passed by reference. But operations on an 'in' parameter will vary depending on the type of variable passed in. For example, if you have a normal struct, then you can call methods on it. In this case, in order to not allow the original struct to be mutated, the compiler will make a 'defensive copy' of the struct (literally an exact copy of its contents in memory), and will pass that a reference to that copy as the "this" to the method it calls. That way if the method tries to change anything, nothing will happen to the original. (Note: that's how calling methods works today when you have something like public readonly MyStruct _s (note: this is a readonly field, not a readonly struct) and you call s.MutatingMethod().

Now, if you pass a readonly struct (i.e. literally a struct declared as readonly struct S { ... }) to an in parameter, the compiler will do something different. Because it know that none of the methods can actually mutate S it will not make the defensive copies when you call methods on it. i.e. the "this" reference it passes to the method will be the same reference passed into the outer method.

[CyrusNajmabadi]

I recommend reading this doc: https://docs.microsoft.com/en-us/dotnet/csharp/reference-semantics-with-value-types

This behavior is called out here:

You can call any instance method that uses pass-by-value semantics. In those instances, a copy of the in parameter is created.

--

Note: defensive copies are also made when accessing things by "ref readonly" members. The compiler doesn't know (for non-readonly-structs) that the methods of that struct will not mutate, so if you call a method on a "ref readonly" returned value, a copy will be made, and the method will be called on that copy.

[JStepien90]

Thanks a lot for the answers. Let’s me clarifying one question. In situation when struct is normal (not marked as read only) any methods is called on the copy of this structure? In this situation I do not see any boost in compare to normal pass struct by value. This approach also do not protect against changing the state of any reference types if struct contains any.

[CyrusNajmabadi]

In situation when struct is normal (not marked as read only) any methods is called on the copy of this structure?

Only:

1. If you are referencing that struct through a readonly field. i.e. public readonly MyStruct _s; ... _s.SomeMethod(); This will cause a copy.
2. If you are calling a method on a struct which is a foreach variable (since a foreach-variable is readonly).
   This will cause a copy.
3. You have a struct in parameter and you call a method on the parameter. This will cause a copy.

I think that's the whole list. But i'm not 100% certain. It may be that a method called on a struct variable used in a dispose block is also copied. But i can't remember.

Basically, in any context where you say the variable is readonly, and you have a struct, the compiler must make a copy (if it's not a "readonly-struct"). After all, if it didn't, then the value could mutate, and you wouldn't really have a readonly-variable would you? :)

[CyrusNajmabadi]

Note: there is a lot of subtlety here that people generally gloss over when using structs (often because structs are immutable anyways, so you don't normally notice this stuff). However, its worthwhile to know if you intend to use these types as deep understanding is necessary to use them properly and to be able to squeeze the maximum perf out of them.

[JStepien90]

Thank you for the comments again! I was surprised that implicit changing any of properties of class passed using in keywords does not generate any error. Right now the whole topic is more clear for me

[DavidArno]

@JStepien90,

As I understand it, in will behave the same as readonly for classes: it prevents re-assignment, but doesn't prevent calling methods that can mutate the inner state of the object.

If you want your object to be immutable, write an immutable class 😀

Maybe someday, we'll get readonly for classes too, which will then enforce readonly for all fields and not allow setters on properties. That'll provide a nice way of having the compiler double check you aren't accidentally mutating a class you meant to be immutable, as well as indicating its immutability to consumers of that type. But that's another feature request.

[benaadams]

Shouldn't passing a class using in just be a compile error then? dotnet/roslyn#23327

I don't understand what purpose it serves other than being a deoptimization

[JStepien90]

I find the benaadams suggestion correct. Perhabs passing the reference types by in should generete a compile error.