Am 19.11.2012 05:57, schrieb deadalnix: > Le 17/11/2012 05:49, Jason House a écrit : >> On Thursday, 15 November 2012 at 16:31:43 UTC, Sean Kelly wrote: >>> On Nov 11, 2012, at 6:30 PM, Walter Bright >>> <newshou...@digitalmars.com> wrote: >>>> >>>> To make a shared type work in an algorithm, you have to: >>>> >>>> 1. ensure single threaded access by aquiring a mutex >>>> 2. cast away shared >>>> 3. operate on the data >>>> 4. cast back to shared >>>> 5. release the mutex >>> >>> >>> So what happens if you pass a reference to the now non-shared object >>> to a function that caches a local reference to it? Half the point of >>> the attribute is to protect us from accidents like this. >> >> The constructive thing to do may be to try and figure out what should >> users be allowed to do with locked shared data... I think the basic idea >> is that no references can be escaped; SafeD rules could probably help >> with that. Non-shared member functions might also need to be tagged with >> their ability to be called on locked, shared data. > > Nothing is safe if ownership cannot be statically proven. This is completely > useless.
But you can at least prove ownership under some limited circumstances. Limited, but (without having tested on a large scale) still practical. Interest seems to be limited much more than those circumstances, but anyway: http://forum.dlang.org/thread/k831b6$1368$1...@digitalmars.com (the same approach that I already posted in this thread, but in a state that should be more or less bullet proof)