On 12/28/2011 4:06 AM, Peter Alexander wrote:
> I rarely *ever* need an immutable string. What I usually need is const(char)[].
> I'd say 99%+ of the time I need only a const string.

I have a very different experience with strings. I can't even remember a case where I wanted to modify an existing string (this includes all my C and C++ usage of strings). It's always assemble a string at one place, and then refer to that string ever after (and never modify it).

What immutable strings make possible is treating strings as if they were value types. Nearly every language I know of treats them as immutable except for C and C++.

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?

Peter, having string as immutable(char)[] was perhaps one of the best D2 decisions so far, in my humble opinion. I strongly disagree with you on this one.

Having a mutable string is a bad idea also because it's mutability is in the form of array element manipulations, but the string (except for the dstring) is not semantically an array and its element mutation isn't safe.

On Wed, Dec 28, 2011 at 9:19 PM, Dejan Lekic <dejan.lekic@gmail.com> wrote:
> Peter, having string as immutable(char)[] was perhaps one of the best D2 decisions so far, in my humble opinion. I strongly disagree with you on this one.



-- 
Bye,
Gor Gyolchanyan.

On 28/12/11 4:27 PM, Andrei Alexandrescu wrote:
> The problem is escaping. A function that transitorily operates on a
> string indeed does not care about the origin of the string, but storing
> a string inside an object is a completely different deal. The setup
>
> class Query
> {
> string name;
> ...
> }
>
> is safe, minimizes data copying, and never causes surprises to anyone
> ("I set the name of my query and a little later it's all messed up!").
>
> 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.

I don't follow your argument. You've said (paraphrasing) "If a function does A then X is best, but if a function does B then Y is best, so Y is best."

If a function needs to store the string then by all means it should use immutable(char)[]. However, this is a much rarer case than functions that simply use the string transitorily as you put it.

Again, there are very, very few functions in Phobos that accept a string as an argument. The vast majority accept `const(char)[]` or `in char[]`. This speaks volumes about how useful the string alias is.

On 12/28/2011 08:00 AM, Ali Çehreli wrote:
> Agreed. I've talked about this in D.learn a number of times myself.

After seeing others' comments that focus more on the alias, I need to clarify: I don't have an opinion on the alias itself.

I agree with the subject line that function parameter lists should mostly have const(char)[] instead of string.

Ali

On 12/28/11 11:42 AM, Peter Alexander wrote:
> On 28/12/11 4:27 PM, Andrei Alexandrescu wrote:
>> The problem is escaping. A function that transitorily operates on a
>> string indeed does not care about the origin of the string, but storing
>> a string inside an object is a completely different deal. The setup
>>
>> class Query
>> {
>> string name;
>> ...
>> }
>>
>> is safe, minimizes data copying, and never causes surprises to anyone
>> ("I set the name of my query and a little later it's all messed up!").
>>
>> 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.
>
> I don't follow your argument. You've said (paraphrasing) "If a function
> does A then X is best, but if a function does B then Y is best, so Y is
> best."

I'm saying (paraphrasing) "X is modularly bankrupt and unsafe, and Y is modular and safe, so Y is best".

> If a function needs to store the string then by all means it should use
> immutable(char)[]. However, this is a much rarer case than functions
> that simply use the string transitorily as you put it.

Rarity is a secondary concern to modularity and safety.

> Again, there are very, very few functions in Phobos that accept a string
> as an argument. The vast majority accept `const(char)[]` or `in char[]`.
> This speaks volumes about how useful the string alias is.

Phobos consists of many functions and few entity types. Application code is rife with entity types. I kindly suggest you reconsider your position; the current setup is indeed very solid.


Andrei

On 12/28/11 11:11 AM, Walter Bright wrote:
> On 12/28/2011 4:06 AM, Peter Alexander wrote:
>> I rarely *ever* need an immutable string. What I usually need is
>> const(char)[].
>> I'd say 99%+ of the time I need only a const string.
>
> I have a very different experience with strings. I can't even remember a
> case where I wanted to modify an existing string (this includes all my C
> and C++ usage of strings). It's always assemble a string at one place,
> and then refer to that string ever after (and never modify it).
>
> What immutable strings make possible is treating strings as if they were
> value types. Nearly every language I know of treats them as immutable
> except for C and C++.

I remember the day at Kahili we figured immutable(char)[] will just work as it needs to. It felt pretty awesome.

Andrei

On 28/12/11 5:11 PM, Walter Bright wrote:
> On 12/28/2011 4:06 AM, Peter Alexander wrote:
>> I rarely *ever* need an immutable string. What I usually need is
>> const(char)[].
>> I'd say 99%+ of the time I need only a const string.
>
> I have a very different experience with strings. I can't even remember a
> case where I wanted to modify an existing string (this includes all my C
> and C++ usage of strings). It's always assemble a string at one place,
> and then refer to that string ever after (and never modify it).

We can disagree on this, but I think the fact that Phobos rarely uses 'string' and instead uses 'const(char)[]' or 'in char[]' speaks louder than either of our experiences.

> What immutable strings make possible is treating strings as if they were
> value types. Nearly every language I know of treats them as immutable
> except for C and C++.

Yes, and I wouldn't want to remove that. Immutable strings are good, but requiring immutable strings when you don't need them is definitely not good. Phobos knows this, so it doesn't use string, which leads me to question what use the string alias is.

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)[].