const?? When and why? This is ugly!

[Walter Bright]

When we first got into what to do with strings and 
const/immutable/mutable, I was definitely in the camp that strings 
should be mutable char[], or at worst const(char)[]. The thing is, 
Andrei pointed out to me, languages that are considered very good at 
dealing with strings (like Perl) use immutable strings. The fascinating 
thing about strings in such languages is:

"Nobody notices they are immutable, they just work."

So what is it about immutability that makes strings "just work" in a 
natural and intuitive manner? The insight is that it enables strings, 
which are reference types, to behave exactly as if they were value types.

After all, it never occurs to anyone to think that the integer 123 could 
be a "mutable" integer and perhaps be 133 the next time you look at it. 
If you put 123 into a variable, it stays 123. It's immutable. People 
intuitively expect strings to behave the same way. Only C programmers 
expect that once they assign a string to a variable, that string may 
change in place.

C has it backwards by making strings mutable, and it's one of the main 
reasons why dealing with strings in C is such a gigantic pain. But as a 
longtime C programmer, I was so used to that I didn't notice what a pain 
it was until I started using other languages where string manipulation 
was a breeze.

The way to do strings in D is to have them be immutable. If you are 
building a string by manipulating its parts, start with mutable, when 
finished then convert it to immutable and 'publish' it to the rest of 
the program. Mutable char[] arrays should only exist as temporaries. 
This is exactly the opposite of the way one does it in C, but if you do 
it this way, you'll find you never need to defensively dup the string 
"just in case" and things just seem to naturally work out.

I tend to agree that if you try to do strings the C way in D2, you'll 
probably find it to be frustrating experience.