View mode: basic / threaded / horizontal-split · Log in · Help
May 26, 2007
Re: string types: const(char)[] and cstring
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/
-------------------------------------
May 26, 2007
Re: string types: const(char)[] and cstring
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 ;)
May 26, 2007
Re: string types: const(char)[] and cstring
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
May 26, 2007
Re: string types: const(char)[] and cstring
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
May 26, 2007
Re: string types: const(char)[] and cstring
== 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.
May 27, 2007
Re: string types: const(char)[] and cstring
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
May 27, 2007
Re: string types: const(char)[] and cstring
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;
May 27, 2007
Re: string types: const(char)[] and cstring
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.
May 27, 2007
Re: string types: const(char)[] and cstring
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
May 27, 2007
Re: string types: const(char)[] and cstring
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.
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home