References in C# are quite similar to those on C++, except that they are garbage collected.
Why is it then so difficult for the C# compiler to support the following:
I wouldn't be surprised if immutable types were added to a future version of C#. There have already been moves in that direction with C# 3.0.
Anonymous types, for example, are immutable.
I think, as a result of extensions designed to embrace parallelism, you will be likely to see immutability pop up more and more.
As Jon already covered (of course) const correctness is not as simple as it might appear. C++ does it one way. D does it another (arguably more correct/ useful) way. C# flirts with it but doesn't do anything more daring, as you have discovered (and likely never well, as Jon well covered again).
That said, I believe that many of Jon's "theoretical reasons" are resolved in D's model.
In D (2.0), const works much like C++, except that it is fully transitive (so const applied to a pointer would apply to the object pointed to, any members of that object, any pointers that object had, objects they pointed to etc) - but it is explicit that this only applies from the variable that you have declared const (so if you already have a non-const object and you take a const pointer to it, the non-const variable can still mutate the state).
D introduces another keyword - invariant - which applies to the object itself. This means that nothing can ever change the state once initialised.
The beauty of this arrangement is that a const method can accept both const and invariant objects. Since invariant objects are the bread and butter of the functional world, and const method can be marked as "pure" in the functional sense - even though it may be used with mutable objects.
Getting back on track - I think it's the case that we're only now (latter half of the naughties) understanding how best to use const (and invariant). .Net was originally defined when things were more hazy, so didn't commit to too much - and now it's too late to retrofit.
I'd love to see a port of D run on the .Net VM, though :-)
The question is, do we need constness in C#?
I'm pretty sure that the JITter knows that the given method is not going to affect the object itself and performs corresponding optimizations automagically. (maybe by emitting call
instead of callvirt
?)
I'm not sure we need those, since most of the pros of constness are performance related, you end up at the point 1.
Besides that, C# has the readonly
keyword.
I suspect there are some practical reasons, and some theoretical reasons:
There's a big one in terms of why it can't be supported now though:
I agree it would be useful to have some sort of constness indicator, but I can't see it happening, I'm afraid.
EDIT: There's been an argument about this raging in the Java community for ages. There's rather a lot of commentary on the relevant bug which you may find interesting.
Mr. Heljsberg, the designer of the C# language has already answered this question:
http://www.artima.com/intv/choicesP.html