string is rarely useful as a function argument

foobar foo at
Wed Dec 28 11:18:31 PST 2011

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.

More information about the Digitalmars-d mailing list