[dmd-concurrency] Defining shared delegates

[Andrei Alexandrescu]

Michel Fortin wrote:
> Le 2010-01-19 à 15:20, Andrei Alexandrescu a écrit :
> 
>> One suggestion about shared delegates: should we take the executive decision to not define them at all? There's nothing you can do with delegates that you can't do with classes. Although generally delegates do justify their existence because they're more comfy than e.g. local classes, it doesn't strike me as obvious we'll need comparable convenience when dealing with shared classes.
> 
> The reason I wrote all this is because I think delegates can be much easier to work with than classes. That's what I tried to demonstrate.
> 
> That's because delegates completely encapsulate the "sharedness" of what they touch, which means that contrary to other types you can implicitly convert a shared delegate to a thread-local one. This should make them much easier to share than most other types, including classes.

I may be missing something, but passing a delegate object across threads 
begets arbitrary sharing of that delegate's state across threads - 
because the delegate can do anything to its data. In fact, many 
functional languages define poor man's classes as delegates that 
dispatch the action depending on arguments. There are examples in e.g. 
SICP (http://mitpress.mit.edu/sicp/).

Andrei