On Wednesday, 28 December 2011 at 19:00:53 UTC, Andrei
Alexandrescu wrote:
On 12/28/11 12:46 PM, Walter Bright wrote:
On 12/28/2011 10:35 AM, Peter Alexander wrote:
On 28/12/11 6:15 PM, Walter Bright wrote:
If such a change is made, then people will use const string
when they
mean immutable, and the values underneath are not guaranteed
to be
consistent.
Then people should learn what const and immutable mean!
I don't think it's fair to dismiss my suggestion on the
grounds that
people
don't understand the language.
People do what is convenient, and as endless experience shows,
doing the
right thing should be easier than doing the wrong thing. If
you present
people with a choice:
#1: string s;
#2: immutable(char)[] s;
sure as the sun rises, they will type the former, and it will
be subtly
incorrect if string is const(char)[].
Telling people they should know better and pick #2 instead is
a strategy
that never works very well - not for programming, nor any
other endeavor.
Oh, one more thing - one good thing that could come out of this
thread is abolition (through however slow a deprecation path)
of s.length and s[i] for narrow strings. Requiring s.rep.length
instead of s.length and s.rep[i] instead of s[i] would improve
the quality of narrow strings tremendously. Also, s.rep[i]
should return ubyte/ushort, not char/wchar. Then, people would
access the decoding routines on the needed occasions, or would
consciously use the representation.
Yum.
Andrei
That's a good idea which I wonder about its implementation
strategy. ATM string is simply an alias of a char array, are you
suggesting string should be a wrapper struct instead (like the
one previously suggested by Steven)?
I'm all for making string a properly encapsulated type.
