Getting the const-correctness of Object sorted once and for all

[Chris Cain]

On Monday, 14 May 2012 at 06:27:15 UTC, Walter Bright wrote:
> On 5/13/2012 11:09 PM, Mehrdad wrote:
>> (1) Compiler helps you write correct multithreaded code
>> (2) You help compiler perform optimizations based on contracts
>> (3) I don't think there exists a #3 that's very different from 
>> #1 and #2
>
> #3 Improves self-documentation of code - it's more 
> understandable and less susceptible to breakage during 
> maintenance.
>
> #4 Improves encapsulation
>
> #5 Makes function purity possible

And all this together culminates into a much greater ability to 
_reason about code_.

Suppose I have code like this:
     immutable item = ...;
     auto res = aPureFunct(item);
     // tons of code
     auto calc = someVal * aPureFunct(item);

Barring the fact that the compiler will probably optimize this 
out for you in D... If you were writing C++ code like this, you 
couldn't tell _almost anything_ about this code based on that 
fragment I gave you. The mere fact that I can tell you 
_something_ is shocking. I can figure out properties and reason 
about code, even in small chunks like this. I know that I can 
replace "aPureFunct(item)" with res and it'll be equivalent.

I'd say that this is my favorite reason (but non-obvious unless 
you actually code using const/immutable):
#6 Reduced cognitive load

I posted this elsewhere, but it also ties multiple things 
together (including the GC):
How about if you're trying to figure out how often a substring of 
length 10 is repeated in some large string (maybe 4 million 
characters long?). In D:
     uint[string] countmap;
     foreach(i; 0..str.length-10)
         ++countmap[str[i..i+10]];

And you're done. Because your string is immutable, D will do the 
correct thing and use pointer+length to the original huge string 
and won't waste time copying things that are guaranteed not to 
change into its hash table. Thanks to the GC, you don't have to 
worry about watching your pointers to make sure they get deleted 
whenever it's appropriate (when you're done, you can just clear 
out countmap and the GC will collect the string if it's not used 
by anyone else...). Presumably the associative array 
implementation could take advantage of both the immutability of 
the string and the purity of toHash to cache the result of 
hashing (although, I'm not certain it does).

Now imagine the code you'd have to write in C++ or many other 
languages to do this _right_. Not just fast, but _also_ correct.

The fact of the matter is that, considering all of D's features, 
the whole is greater than the sum of its parts. Can you find 
something wrong with each part? Of course. But the fact of the 
matter is that each of them support each other in such a way that 
they synergistically improve the language ... if you take any one 
of them away, you would be left with everything else being less 
useful than before.

This is why you really ought to spend some time with const and 
immutable (and, yeah, they're mostly inseparable) and really get 
to know what it enables you to do. Tons of features and 
capabilities depend on it, so it's really not something that 
"should be gotten rid of to make the language more marketable". 
I'm not saying I wouldn't use D if we lost const/immutable, but 
it would certainly sour my experience with it.