Walter Bright wrote:
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.
That hit the spot.
Andrei
