string is rarely useful as a function argument

Timon Gehr timon.gehr at gmx.ch
Wed Dec 28 11:38:53 PST 2011


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?




More information about the Digitalmars-d mailing list