Possible to pass a member function to spawn?

[Jacob Carlborg]

On 2012-02-08 00:32, Sean Kelly wrote:
> On Feb 7, 2012, at 3:09 PM, Manu wrote:
>
>> On 8 February 2012 00:33, Sean Kelly<sean at invisibleduck.org>  wrote:
>> On Feb 6, 2012, at 1:38 PM, Oliver Puerto wrote:
>>
>>> Hello,
>>>
>>> I'm very new to D. Just started reading "The D programming language". I should read it from beginning to end before posting questions here. I know ... But I'm just too impatient. The issue seems not to be that simple, nevertheless. The code below compiles with Visual Studio.
>>>
>>> I want to have something like my actor class that I can start running in it's own thread like in Scala or other languages that support actors. So at best, I would like to do something like this:
>>>
>>>     MyActor myActor = new MyActor();
>>>     auto tid = spawn(&start,&myActor.run());
>>
>> This should work:
>>
>> void runActor(shared MyActor a) { (cast(MyActor)a)).run(); }
>> MyActor myActor = new MyActor();
>> auto tid = spawn(cast(shared MyActor) myActor,&runActor);
>>
>> See, my conclusion is, whenever using this API, you inevitably have dog ugly code. That code is barely readable through the casts... I can only draw this up to faulty API design.
>> I understand the premise of 'shared'-ness that the API is trying to assert/guarantee, but the concept is basically broken in the language. You can't use this API at all with out these blind casts, which is, basically, a hack, and I am yet to see an example of using this API 'properly'. The casts are totally self defeating.
>
> In this case, an alternative would be to create the actor in the spawned thread:
>
> void run() {
>      auto a = new Actor;
>      a.run();
> }
> spawn(&run);
>
> Regarding shared as it applies to classes… one reason it hasn't been built out in druntime yet is because the original intent was for shared methods to basically end up with compiler-generated memory barriers all over the place and this was sufficiently unappealing that I didn't want to support it.  As far as I'm aware, this is no longer planned, but the transitivity of shared can still make for some weirdness at the implementation level.  For example, if I have:

Then what's "shared" supposed to do?

-- 
/Jacob Carlborg