Something needs to happen with shared, and soon.

[Sönke Ludwig]

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.