Value types, Immutability (Good) and Mutability (Evil) in .NET.

Question

Recently, I read a lot of literature on Types of values ​​and types of links and their differences. This question surrounds the topic of variability and immutability of value types.

Based on what I read, it seems that value types in .NET should be written in such a way that they are immutable; that is, after they are assigned a value, the value of this type in memory never changes. Only subsequent copies of the type can create new instances in memory with new values ​​based on the original. It would seem that volatility in .NET is evil.

To clarify the understanding of immutability (for my own sanity and for others), I have demonstrated this below:

DateTime and TimeSpan are examples of immutable structures, because once a value has been assigned to an instance, the value of this instance cannot be changed, this is evident thanks to readonly properties:

 DateTime dt = new DateTime(); DateTime newdt = dt.AddDays(2); // Okay, new value stored in newdt newdt.Year = 1945; // Error, cannot write to readonly property 

However, immutability can be confusing when looking for primitive types such as Int32 , Double or Char , because the types seem mutable, but my gut feeling is that immutability is actually handled transparently through the CLR; take, for example, the following operations (I commented on some very simple x86 equivalents to understand how immutability is handled in terms of a primitive type)

 int x = 0; // xor eax, eax; 'clear register to 0 // push eax; 'push eax (0) onto the stack x = 5; // pop eax; 'pop stack (0) into eax // mov eax, 5; 'eax = 5 // push eax; 'push eax (5) onto the stack x++; // pop eax; 'pop stack (5) into eax // add eax, 1; 'eax = 5 + 1 // push eax; 'push eax (6) onto the stack 

Everything is good and good so far; Microsoft seems to be doing a good job of introducing immutability into its value types; but then we start finding bad apples, and the subelements that make volatility look good, and lul developers look in the false sense of security!

I am talking about Point , Size , Rectangle (and several others) in System.Drawing .

Suddenly we are given the opportunity to change the type of value according to its properties, and I have a theory why this is possible; take for example the following code

 Point p = new Point(); pX = 100; pY = 200; // Immutability (had it been implemented here) might infer the following usage Point p = new Point(100, 200); Point p2 = p.AddXY(200, 300); 

However, as said, I had a theory as to why these structures are mutable:

• Microsoft just wanted to simplify working with these structures.
• They are compatible with their own GDI / GDI + calls, so their behavior was developed around their own C / C ++ counterparts.

So finally my questions are:

• I fully embraced and understood the immutability and variability?
• Should developers strive to create immutable structures, as a rule?
• When is it acceptable to create mutable structures?

Answer 1

The variability problem does not apply to the reference type value vs. There are examples for both. Take System.String as an example for an immutable class, as well as your example System.Drawing.Point as an example of a mutable structure.

Mutable vs. immutable is a constructive solution based on the use of this type. Whether this reference or value type is another design decision that is independent of the first.

Answer 2

Hmm ... It will probably be closed soon, but here's my look at that.

• Yes, it seems you understand immutability and mutability.
• There must be a big word. Developers should be aware of the differences, take care of their trading, and have common sense to ask themselves the question: what do I need from this particular structure.
• Acceptable? I think when you need it. The question of when you need it is a completely different question.

Usually you use structures to store some properties or types of primitives. There are articles about what you should and should not have in your structures so that they can end on a heap or a stack, but this is out of scope here. If you have a good reason to use a mutable structure and you are documenting it so that the next developer knows why, this is normal.
If on the contrary, you do not care, and the documentation is small on your list, well, it really does not matter what is acceptable or not :).