Shared Delegates

[Andrew Wiley]

On Tue, Oct 18, 2011 at 1:48 AM, Andrew Wiley <wiley.andrew.j at gmail.com>wrote:

> On Tue, Oct 18, 2011 at 1:11 AM, Benjamin Thaut <code at benjamin-thaut.de>wrote:
>
>> Am 18.10.2011 08:03, schrieb Andrew Wiley:
>>
>>> On Tue, Oct 18, 2011 at 12:53 AM, Benjamin Thaut <code at benjamin-thaut.de
>>> <mailto:code at benjamin-thaut.de**>> wrote:
>>>
>>>    Am 17.10.2011 22:43, schrieb Michel Fortin:
>>>
>>>        On 2011-10-17 20:33:59 +0000, Andrew Wiley
>>>        <wiley.andrew.j at gmail.com <mailto:wiley.andrew.j at gmail.**com<wiley.andrew.j at 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<http://3d.benjamin-thaut.de/?__p=18><
>>> http://3d.benjamin-thaut.de/?**p=18 <http://3d.benjamin-thaut.de/?p=18>>
>>>
>>>
>>>
>>> Ah, I was looking through the bug reports and didn't see this exact bug.
>>> Did I just fail at searching, or should I file it?
>>>
>>>
>> I didn't file it yet, so file it. I do however think that currently there
>> is no intention in changing the way shared works.
>>
>>
> This much is clearly a bug, and Michel's explanation of how shared
> delegates should work makes a lot of sense.
>

Filed as http://d.puremagic.com/issues/show_bug.cgi?id=6823
For now, I can just cast things at the call site.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111018/8acb140c/attachment-0001.html>