On 12/28/2011 08:18 PM, foobar wrote:
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.
In what way would the proposed change improve encapsulation, and why
would it even be desirable for such a basic data structure?
