Am 17.10.2011 22:43, schrieb Michel Fortin:

On 2011-10-17 20:33:59 +0000, Andrew Wiley <wiley.andrew.j@gmail.com> said:

Okay, I realize there have been some discussions about this, but I have a
few questions about shared delegates because right now they are
definitely
broken, but I'm not sure how.
Take this code example:

synchronized class Thing {
void doSomeWork(void delegate() work) {
work();
}
void work() {}
}

void main() {
auto th = new Thing();
th.doSomeWork(&th.work);
}

This doesn't compile because the type of "&th.work" is "void delegate()
shared", which cannot be cast implicitly to "void delegate()".
My first question would be whether that type is correct. It's true
that the
data pointer of the delegate points to a shared object, but given that
the
function locks it, does that really matter in this case? I guess I'm just
not clear on the exact meaning of "shared" in general, but it seems like
whether the data is shared or not is irrelevant when the delegate
points to
a public member of a synchronized class. If it was a delegate pointing
to a
private/protected member (which should be illegal in this case), that
would
not be true.
If that type is correct, the problem is that "void delegate() shared"
doesn't parse as a type (there is a workaround because you can create
variables of this type through alias and typeof).

What, exactly, is wrong here?

I think what's wrong is that a shared delegate should implicitly convert
to a non-shared one. The delegate is shared since it can be called
safely from any thread, and making it non-shared only prevent you from
propagating it to more thread so it's not harmful in any way.

I reported this exact issue already a few months ago and simply didn't get any comment on it. If you really try to use shared to are going to hit more such problems.

See the shared section of my blogpost: http://3d.benjamin-thaut.de/?p=18