const?? When and why? This is ugly!

[Steve Schveighoffer]

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

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

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: :(

-Steve