Immutable and unique in C#

[Sönke Ludwig]

Am 12.11.2012 04:06, schrieb Jonathan M Davis:
> On Sunday, November 11, 2012 17:29:02 Walter Bright wrote:
>> I'm not convinced that adding a "unique" qualifier is strictly necessary.
> 
> Where it would be particularly valuable would be passing stuff across threads 
> with std.concurrency. We don't _need_ it for that however. It would just make 
> it cleaner, because you wouldn't have to worry about whether anything else on 
> the current thread had a reference to what you were passing across.

Exactly, that's the main point. That it would also allow to operate
safely on an already constructed unique value (which is the possible
implicit precursor to an immutable value) is just a nice bonus.

> 
> So, while I think that it would be nice, I'm not convinced that it's worth 
> adding at this point. There's a halfway decent chance that you'd just end up 
> casting to unique to pass it across anyway (depending on how the value was 
> constructed), which then puts us in exactly the same boat that we're in now 
> except for the fact that we're casting to unique instead of casting to shared 
> or immutable.
> 
> - Jonathan M Davis
> 

Sorry, but following that argument, we can also drop
const/immutable/shared. After all there is a chance that they are just
forced using a cast and thus don't buy us anything... The point is of
course to bring the type system closer to a point where such casts are
not needed at all. The programmer would then know that doing such a cast
is probably wrong - right now casting is necessary far too often and as
such looses its usually implied warning sign.

But apart from that, I have started to explore a bit what's possible
using a library solution. So far it looks quite promising, I'll post a
snippet later.