On 12/28/2011 08:00 PM, 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.
Why? char and wchar are unicode code units, ubyte/ushort are unsigned
integrals. It is clear that char/wchar are a better match.
Then, people would access the decoding routines on the needed occasions,
or would consciously use the representation.
Yum.
Andrei
