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
