The "no gc" crowd

[Jonathan M Davis]

On Thursday, October 10, 2013 10:27:24 Sean Kelly wrote:
> On Oct 9, 2013, at 9:24 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> > And given that std.concurrency requires casting to and from shared or
> > immutable in order to pass objects across threads, it seems ilke most of
> > D's concurrency model requires casting to and/or from shared or
> > immutable.
> std.concurrency won't be this way forever though. We could fake move
> semantics with something like assumeUnique!T, so send could be modified to
> accept a non-shared class that's marked as Unique.

I take it that you mean something other than std.exception.assumeUnique which 
simply casts to immutable? All that std.exception.assumeUnique does for you 
over casting is document why the cast is happening.

If you're talking about creating a wrapper type which indicates that the 
object is unique, I'd still expect that the casting would have to be happening 
underneath the hood when the object was passed (though then for better or 
worse, it would be encapsulated). And unless the objecte were always in that 
Unique wrapper, the programmer would still have to be promising that the 
object was actually unique and not being shared across threads rather than the 
type system doing it, in which case, I don't see much gain over simply 
casting. And if it's always in the wrapper, then you're in a similar boat to 
shared or immutable in that it's not the correct type.

I expect that there are nuances in what you're suggesting that I don't grasp 
at the moment, but as far as I can tell, the type system fundamentally 
requires a cast when passing objects across threads. It's just a question of 
whether that cast is hidden or not, and depending on how you hide it, I think 
that there's a real risk of the situation being worse than if you require 
explicit casting, because then what you're doing and what you have to be 
careful about are less obvious, since what's going on is hidden.

> The other option would be deep copying or serialization.

That would be far too costly IMHO. In the vast majority of cases (in my 
experience at least and from what I've seen others do), what you really want 
to do is pass ownership of the object from one thread to the other, and while 
deep copying would allow you to avoid type system issues, it's completely 
unnecessary otherwise. So, we'd be introducing overhead just to satisfy our 
very restrictive type system. The only way that I can think of to fix that 
would be for objects to all have a concept of what thread owns them (so that 
the type system would be able to understand the concept of an object's 
ownership being passed from one thread to another), but that would be a _big_ 
change and likely way too complicated in general.

- Jonathan M Davis