View mode: basic / threaded / horizontal-split · Log in · Help
December 28, 2011
Re: string is rarely useful as a function argument
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."
December 28, 2011
Re: string is rarely useful as a function argument
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.
December 28, 2011
Re: string is rarely useful as a function argument
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.
December 28, 2011
Re: string is rarely useful as a function argument
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.
December 28, 2011
Re: string is rarely useful as a function argument
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.
December 28, 2011
Re: string is rarely useful as a function argument
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.
December 28, 2011
Re: string is rarely useful as a function argument
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
December 28, 2011
Re: string is rarely useful as a function argument
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
December 28, 2011
Re: string is rarely useful as a function argument
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.
December 28, 2011
Re: string is rarely useful as a function argument
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?
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home