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.
