On 12/28/2011 07:07 PM, Peter Alexander wrote:
> On 28/12/11 5:16 PM, Walter Bright wrote:
>> On 12/28/2011 5:16 AM, Peter Alexander wrote:
>>> Any time you want to create a string without allocating memory.
>>>
>>> char[N] buffer;
>>> // write into buffer
>>> // try to use buffer as string
>>
>> Is the buffer ever going to be reused with a different string in it?
>
> Possibly.
>
> I know what argument is coming next: "But if the function you call
> stores the string you passed in then it can't rely on seeing a
> consistent value!"
>
> I know this. These functions should request immutable(char)[] because
> that's what they need. Functions that don't store the string should use
> const(char)[].
>
> The question is whether string should alias immutable(char)[] or
> const(char)[]. In my experience (which is echoed in Phobos) is that
> const(char)[] is used much more often than immutable(char)[], so it
> should alias const(char)[].

You are approximately saying (paraphrasing): "The question is whether a cow is a cow or an animal. In my experience (which is echoed at the farm down the valley) is that there are more animals than there are cows. So we should call all our animals cows."

On 12/28/2011 10:07 AM, Peter Alexander wrote:
> On 28/12/11 5:16 PM, Walter Bright wrote:
>> On 12/28/2011 5:16 AM, Peter Alexander wrote:
>>> Any time you want to create a string without allocating memory.
>>>
>>> char[N] buffer;
>>> // write into buffer
>>> // try to use buffer as string
>>
>> Is the buffer ever going to be reused with a different string in it?
>
> Possibly.
>
> I know what argument is coming next: "But if the function you call stores the
> string you passed in then it can't rely on seeing a consistent value!"

Exactly.


> I know this. These functions should request immutable(char)[] because that's
> what they need. Functions that don't store the string should use const(char)[].
>
> The question is whether string should alias immutable(char)[] or const(char)[].
> In my experience (which is echoed in Phobos) is that const(char)[] is used much
> more often than immutable(char)[], so it should alias const(char)[].

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.

On 28/12/11 6:03 PM, Timon Gehr wrote:
> On 12/28/2011 07:07 PM, Peter Alexander wrote:
>> On 28/12/11 5:16 PM, Walter Bright wrote:
>>> On 12/28/2011 5:16 AM, Peter Alexander wrote:
>>>> Any time you want to create a string without allocating memory.
>>>>
>>>> char[N] buffer;
>>>> // write into buffer
>>>> // try to use buffer as string
>>>
>>> Is the buffer ever going to be reused with a different string in it?
>>
>> Possibly.
>>
>> I know what argument is coming next: "But if the function you call
>> stores the string you passed in then it can't rely on seeing a
>> consistent value!"
>>
>> I know this. These functions should request immutable(char)[] because
>> that's what they need. Functions that don't store the string should use
>> const(char)[].
>>
>> The question is whether string should alias immutable(char)[] or
>> const(char)[]. In my experience (which is echoed in Phobos) is that
>> const(char)[] is used much more often than immutable(char)[], so it
>> should alias const(char)[].
>
> You are approximately saying (paraphrasing): "The question is whether a
> cow is a cow or an animal. In my experience (which is echoed at the farm
> down the valley) is that there are more animals than there are cows. So
> we should call all our animals cows."

No, I'm saying that people talk about animals more often than cows, so it should be easier and more intuitive to say "animal" than it is to say "cow". People can still call things cows if that is what they're talking about.

On 28/12/11 6:15 PM, Walter Bright wrote:
> On 12/28/2011 10:07 AM, Peter Alexander wrote:
>> The question is whether string should alias immutable(char)[] or
>> const(char)[].
>> In my experience (which is echoed in Phobos) is that const(char)[] is
>> used much
>> more often than immutable(char)[], so it should alias const(char)[].
>
> 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.

On Wednesday, 28 December 2011 at 16:27:15 UTC, Andrei Alexandrescu wrote:
> So immutable(char)[] is the best choice for a correct string abstraction compared against both char[] and const(char)[]. In fact it's in a way good that const(char)[] takes longer to type, because it also carries larger liabilities.

Also, 'in char[]', which is conceptually much safer, isn't that much longer to type.

It would be cool if 'scope' was actually implemented apart from an optimization though.

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.

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.

Yes. Contrary to the OP, I don't think it's fair to dismiss a valid concern by framing it as a user education issue. It's has very often been aired in the olden days of C++, and never in a winning argument. (Right off the bat - auto_ptr.)

Andrei

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

On 12/28/2011 10:56 AM, Andrei Alexandrescu wrote:
> Yes. Contrary to the OP, I don't think it's fair to dismiss a valid concern by
> framing it as a user education issue. It's has very often been aired in the
> olden days of C++, and never in a winning argument. (Right off the bat - auto_ptr.)

And as Bruce Eckel discovered, even the people who know better will deliberately pick the wrong method, because it's easier, and they justify it to themselves by saying they'll go back and fix it later. And of course that doesn't happen.

Bruce decided there was something fundamentally wrong with a feature that he'd actually write articles about exhorting people to do X instead of Y, and then in his own code he preferred to do the simpler Y.

On Wed, 28 Dec 2011 11:00:52 -0800, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> 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

Would slicing, i.e. s[i..j] still be valid? If so, what would be the recommended way of finding i and j?