The "no gc" crowd

[Sean Kelly]

On Oct 10, 2013, at 10:50 AM, "Jonathan M Davis" <jmdavisProg at gmx.com> wrote:

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

Yes, we couldn't use assumeUnique as-is because then the object would land on the other side as immutable.  It would have to wrap the object to tell send() that the object, while not shared or immutable, is safe to put in a message.  Then send() would discard the wrapper while constructing the message.