const?? When and why? This is ugly!

[Andrei Alexandrescu]

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.

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.

> 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.

> 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.

> 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.


Andrei