On Sun, 08 Mar 2009 19:24:32 -0700, Andrei Alexandrescu wrote:

> Steve Schveighoffer wrote:
>> On Sun, 08 Mar 2009 17:24:09 -0700, Walter Bright wrote:
>> 
>>> Derek Parnell wrote:
>>>> I know that a better way to code this example would have been to use the .idup functionality, but that is not the point. I relied on the compiler ensuring that everything declared as immutable would not be modified. The compiler failed.
>>> It is the same issue. When you use a cast, you are *explicitly* defeating the language's type checking ability. It means that the onus is on the one doing the cast to get it right.
>> 
>> Except when you want invariant data, then cast is *required*.
> 
> Not at all. Calling idup (or, more elegantly, to!TargetType) or assumeUnique under the circumstances documented by assumeUnique are all safe. Sometimes the price for added safety is one extra copy. But the added safety is worth it more often than not.

idup is not a viable option in certain cases, if memory usage or performance are important.  It might not even be available if the object in question doesn't implement a function that does it.  assumeUnique suffers from the same problems as casting.  It just avoids any potential casting that changes types instead of constancy.

I agree that in 90% of cases, using invariant strings is beneficial, and not a burden.  I think the arguments against are for those small cases where performance is significantly hindered, and having a library which uses string where it should use in char[] makes life difficult for those cases.  I understand you are fixing this, so that is good.

> 
> As far as signatures of functions in std.string, I agree that those not needing a string of immutable characters should just accept in Char[] (where Char is one of the three character types). That should make people using mutable and immutable strings equally joyous.
> 

What might be useful is coming up with an alias for char[], like mstring or something that shakes off the notion that a mutable char[] is not a string.

>> At that
>> point, it is a language feature, not a defeat of the typesystem.  I
>> think there is some merit to the arguments presented in this thread,
>> but I don't think the answer is to get rid of invariant.  Perhaps make
>> the compiler more strict when creating invariant data?  I liked the
>> ideas that people presented about having unique mutable references
>> (before and in this thread).  This might even be solvable in a library
>> given all the advances in structs.
> 
> Unique has been discussed extensively a couple of years ago when we were defining const and immutable. We decided to forgo it and go with assumeUnique.

I see in your reply to walter that it could be done with some bug fixes, I think this should be an important step to make.

>> So it's not exactly the same issue, because in one you are doing something totally useless and stupid.  And in the other, it is a language *requirement* to use casting to get invariant data.  However, in both cases, the onus is on the developer, which sucks in the latter case...
> 
> NO. It is not a language requirement. If what you have is mutable data and someone else wants immutable data, make a copy.

Unless copying hinders performance so much that you would rather take the safety hit and start casting.  Imagine having to copy every message that was received on a network stream just so you could use string functions on it.  Or having to duplicate all the data read into a small buffer from a file just to search for strings in it.

>> Walter: Use invariant when you can, it's the best! User: ok, how do I
>> use it?
>> Walter: You need to cast mutable data to invariant, but it's on you to
>> make sure nobody changes the original mutable data.  Casting
>> circumvents the typesystem, so the compiler can't help you. User: :(
> 
> Casts to immutable should not be part of most programs.

assumeUnique is a cast.  You have not avoided that.  The extra steps it goes through is not enough to quiet this discussion.  We are not talking about using assumeUnique or casting everywhere in a program.  We are talking about how difficult it is to call functions that take strings when they should take const(char)[] (a practice that is going to continue since the string label has been attached to immutable(char)[] only) in the rare cases when you need the functions.

-Steve