Derek Parnell wrote:

>> Under the new const/invariant/final regime, what are strings going to be ? Experience with other languages suggest that strings should be immutable.
> 
> We seem to have different experience. Most of the code I write deals with changing strings - in other words, manipulating strings is very very common in the sorts of programs I write.
> 

The same here. I don't have much experience with Java and really don't know why const strings are so usefull...

Maybe someone could elaborate a little bit more?

-- 
Regards
Marcin Kuszczak (Aarti_pl)
-------------------------------------
Ask me why I believe in Jesus - http://zapytaj.dlajezusa.pl (en/pl)
Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/
-------------------------------------

Marcin Kuszczak wrote:

> Derek Parnell wrote:
> 
>>> Under the new const/invariant/final regime, what are strings going to be ? Experience with other languages suggest that strings should be immutable.
>> 
>> We seem to have different experience. Most of the code I write deals with changing strings - in other words, manipulating strings is very very common in the sorts of programs I write.
>> 
> 
> The same here. I don't have much experience with Java and really don't know why const strings are so usefull...
> 
> Maybe someone could elaborate a little bit more?
> 

In my experience they are not really usefull at all (const as in constant that is). Sometimes it does not matter and sometimes it is inconvenient or a performance problem. (it is mostly append that is needed in my experience)

If function parameters was const by default (as in the new behavior of in) I see no use of immutability here. In java I think it is used to prevent aliased String objects from changing value, something that could create unexpected bugs if used by programmers not understanding aliasing.

ps. although I'm no fan of java I have used it for most university assignments for the past two years, so hopfully I'm not totally wrong ;)

Marcin Kuszczak wrote:
> Derek Parnell wrote:
> 
>>> Under the new const/invariant/final regime, what are strings going to be
>>> ? Experience with other languages suggest that strings should be
>>> immutable.
>> We seem to have different experience. Most of the code I write deals with
>> changing strings - in other words, manipulating strings is very very
>> common in the sorts of programs I write.
>>
> 
> The same here. I don't have much experience with Java and really don't know
> why const strings are so usefull... 
> 
> Maybe someone could elaborate a little bit more?

Ditto here.  When I've used java I found it more annoying that strings were immutable than anything else.

--bb

Walter Bright wrote:
> Under the new const/invariant/final regime, what are strings going to be ? Experience with other languages suggest that strings should be immutable. To express an array of const chars, one would write:
> 
>     const(char)[]
> 
> but while that's clear, it doesn't just flow off the keyboard. Strings are so common this needs an alias, so:
> 
>     alias const(char)[] cstring;
> 
[snip]

If you decide on an alias it would be a good idea to add it to phobos for DMD 1, except without the const syntax of course.  That way people can start using it now and have less problems upgrading to DMD 2. Although, on the other hand, it may be slightly confusing on 1.0 coders I guess when it doesn't function as a const string.

-Joel

== Quote from Bill Baxter (dnewsgroup@billbaxter.com)'s article
> Marcin Kuszczak wrote:
> > Derek Parnell wrote:
> >
> >>> Under the new const/invariant/final regime, what are strings going to be ? Experience with other languages suggest that strings should be immutable.
> >> We seem to have different experience. Most of the code I write deals with changing strings - in other words, manipulating strings is very very common in the sorts of programs I write.
> >>
> >
> > The same here. I don't have much experience with Java and really don't know why const strings are so usefull...
> >
> > Maybe someone could elaborate a little bit more?
> Ditto here.  When I've used java I found it more annoying that strings
> were immutable than anything else.
> --bb

I found it more bothersome by far that Integer, Float, etc were immutable. Even after going through all the trouble of getting classes for all these, you couldn't use them for out or inout parameters to functions.

Scratch that -- what was really annoying was that you couldn't ever *specify* how
you wanted your parameter. Even in C, you can pass an address (but then,
anything's possible in C). But in Java, you can only call by reference with a
class or an array, so you end up doing things like:
void foo(int[1] inout_parameter) { inout_parameter[0] += 5; }

And the only way to get scope const final sort of deal on a class is to copy and then submit the copy as a final parameter -- it's the reference, not the data, that's final.

In short, thank you, Walter, for allowing us to pass anything by reference, and by allowing the data referenced to be made read-only.

Marcin Kuszczak wrote:
> Derek Parnell wrote:
> 
>>> Under the new const/invariant/final regime, what are strings going to be
>>> ? Experience with other languages suggest that strings should be
>>> immutable.
>> We seem to have different experience. Most of the code I write deals with
>> changing strings - in other words, manipulating strings is very very
>> common in the sorts of programs I write.
>>
> 
> The same here. I don't have much experience with Java and really don't know
> why const strings are so usefull... 
> 
> Maybe someone could elaborate a little bit more?
> 

It might also be educational to look at Python, which also has immutable strings.

The first, and probably most important reason why strings are immutable in Python is so they can be used as hash keys. (Mutating an object being used as a hash key is bad, bad, bad.)

Other reasons are addressed here:
http://effbot.org/pyfaq/why-are-python-strings-immutable.htm

However, Python is a very different kind of language from D. Using strings as hash keys is extraordinarily important in Python, as the use of any identifier is in essence a hash lookup.

Providing immutable strings in D is very useful (so the compiler can enforce copy-on-write semantics, for instance), and I don't think anyone would dispute that. The issue seems to be whether the "default" string alias should be immutable. I would say, since D seems to subscribe to copy-on-write semantics, that it should be. And of course, if you need mutable strings, you will always be able to declare a char[].

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org

Derek Parnell wrote:
> We seem to have different experience. Most of the code I write deals with
> changing strings - in other words, manipulating strings is very very common
> in the sorts of programs I write.

You'll still be able to concatenate and slice invariant strings. You can also cast a char[] to an invariant, when you're done building it.

> So 'const(char)[] x' means that I can change x.ptr and x.length but I
> cannot change anything that x.ptr points to, right?

Right.

> And  'invariant(char)[] x' means that I cannot change x.ptr or x.length and
> I cannot change anything that x.ptr points to, right?

Wrong. The difference between const and invariant is that invariant is truly, absolutely, immutable. Const is only immutable through the reference - another reference to the same data can change it.

> So what syntax is to be used so that x.ptr and x.length cannot be changed
> but the characters referred to by 'x' can be changed?

final char[] x;

gareis wrote:
> In short, thank you, Walter, for allowing us to pass anything by reference, and by
> allowing the data referenced to be made read-only.

You're welcome. Different languages offer different pieces, only D will offer the whole customizable shebang. The idea is for programs to be more self-documenting, and so make automated analysis more feasible.

Walter Bright wrote:
> Derek Parnell wrote:
>> We seem to have different experience. Most of the code I write deals with
>> changing strings - in other words, manipulating strings is very very common
>> in the sorts of programs I write.
> 
> You'll still be able to concatenate and slice invariant strings. You can also cast a char[] to an invariant, when you're done building it.
Will there be something in the type system which enables you to safely say, "This is the only reference to this data, so it's ok for me to make this invariant" ? Does 'scope' happen to have anything to do with that?

invariant(char)[] createJunk()
{
    /* scope? */ char[] val = "aaaaa".dup;
    size_t index = rand() % 5;
    val[index] = rand();

    return cast(invariant(char)[]) val;
}

I mean, do I really need to cast it to invariant there? It's easy to see that there's only one copy of val's data in existance.

  -- Reiner

Reiner Pope wrote:
> Will there be something in the type system which enables you to safely say, "This is the only reference to this data, so it's ok for me to make this invariant" ?

Safely? No. You will be able to explicitly cast to invariant, however, the programmer will have to ensure it is safe to do so.

> Does 'scope' happen to have anything to do with that?

No. Scope just ensures that the reference does not 'escape' the scope it's in.

> invariant(char)[] createJunk()
> {
>     /* scope? */ char[] val = "aaaaa".dup;
>     size_t index = rand() % 5;
>     val[index] = rand();
> 
>     return cast(invariant(char)[]) val;
> }
> 
> I mean, do I really need to cast it to invariant there? It's easy to see that there's only one copy of val's data in existance.

Easy for you to see, not so easy for the compiler to. And besides:

	return cast(invariant)val;

will do the trick more conveniently.