Am 16.11.2012 14:17, schrieb Michel Fortin: > > Only if you can make a proxy object that cannot leak a reference. It's > already not obvious how to > not leak the top-level reference, but we must also consider the case where > you're protecting a data > structure with the mutex and get a pointer to one of its part, like if you > slice a container. > > This is a hard problem. The language doesn't have a solution to that yet. > However, having the link > between the access policy and the variable known by the compiler makes it > easier patch the hole later. > > What bothers me currently is that because we want to patch all the holes > while not having all the > necessary tools in the language to avoid escaping references, we just make > using mutexes and things > alike impossible without casts at every corner, which makes things even more > bug prone than being > able to escape references in the first place. > > There are many perils in concurrency, and the compiler cannot protect you > from them all. It is of > the uttermost importance that code dealing with mutexes be both readable and > clear about what it is > doing. Casts in this context are an obfuscator. >
Can you have a look at my thread about this? http://forum.dlang.org/thread/k831b6$1368$1...@digitalmars.com I would of course favor a nicely integrated language solution that is able to lift as many restrictions as possible, while still keeping everything statically verified [I would also like to have a language solution to Rebindable!T ;)]. But as an alternative to just a years lasting discussion, which does not lead to any agreed upon solution, I'd much rather have such a library solution - it can do a lot, is reasonably pretty, and is (supposedly and with a small exception) fully safe.
