What does the CLR do with immutable structures?

I've been rea开发者_开发知识库ding a bit about immutable structures such as string. Simply put, they don't change state once they've been created (so for instance asking for a substring gives you a new string).

Now, I was wondering whether the CLR "knows" that a certain type is immutable, and uses this fact to do something clever at runtime, or is immutability mainly something that makes certain scenarios simpler to program?

In general the CLR doesn't do anything special with immutable types. They are treated in the same way as any other types.

For strings there is special support. Strings can be interned and reused. In C#, source code string literals are automatically interned by the compiler. You can also intern a string yourself by calling String.Intern.

Potentially, it could be possible for the compiler (rather than the CLR) to do something clever with it in producing IL. I don't know if it does, and honestly don't care: If it doesn't maybe it will in the future (later versions). If it does, maybe it won't in the future (an edge-case is found showing the optimisation to be ill-advised.

I'm happy to think "well, if this is readonly then maybe the compiler (or indeed, the CLR) will do something clever with it, so that'll be a free improvement". It'll be a free improvement because I'm never going to make something readonly to take advantage of such optimisations even if I learn that it definitely does so and that such savings are great. I will only ever make something readonly if it makes sense to be readonly. I do this a lot because my style favours heavy use of immutable objects, but I will only do it because the object is logically immutable, rather than make it immutable in pursuit of some optimisation and then have to workaround the immutability.

Of course, there are also certain ways that you can be clever with immutable objects (in particular, when working out the effects of different multi-threaded scenarios will have on your code).

In the CLR's perspective the value IS MUTABLE. For example : the CLR can change the object's data to perform caching. The users of the structure can't change it's value, but the CLR can do it in several scenarios. That's why the CLR can't enforce the immutability on itself and can't relay on it during the runtime.

Neither the compiler nor .net does anything with immutable structures that it doesn't do with mutable ones, although it does do some things with structures which are semantically valid only if they happen to be immutable. For example, if a structure is cast to Object, the compiler will create a new boxed instance of the structure initialized with the same data as the original. If the structure is mutable, the new instance will not be semantically the same as the original, since changes to one instance will not affect the other. There are some other circumstances where compilers copy structures and pretend the copies are semantically interchangeable with the originals; unfortunately, I don't know any way to request that situations which would cause such implicit copies should raise a compile-time error rather than letting the copies happen.