Something needs to happen with shared, and soon.

[Sönke Ludwig]

Am 15.11.2012 05:32, schrieb Andrei Alexandrescu:
> On 11/14/12 7:24 PM, Jonathan M Davis wrote:
>> On Thursday, November 15, 2012 03:51:13 Jonathan M Davis wrote:
>>> I have no idea what we want to do about this situation though. Regardless of
>>> what we do with memory barriers and the like, it has no impact on whether
>>> casts are required. And I think that introducing the shared equivalent of
>>> const would be a huge mistake, because then most code would end up being
>>> written using that attribute, meaning that all code essentially has to be
>>> treated as shared from the standpoint of compiler optimizations. It would
>>> almost be the same as making everything shared by default again. So, as far
>>> as I can see, casting is what we're forced to do.
>>
>> Actually, I think that what it comes down to is that shared works nicely when
>> you have a type which is designed to be shared, and it encapsulates everything
>> that it needs. Where it starts requiring casting is when you need to pass it
>> to other stuff.
>>
>> - Jonathan M Davis
> 
> TDPL 13.14 explains that inside synchronized classes, top-level shared is automatically lifted.
> 
> Andrei

There are three problems I currently see with this:

 - It's not actually implemented
 - It's not safe because unshared references can be escaped or dragged in
 - Synchronized classes provide no way to avoid the automatic locking in certain methods, but often
it is necessary to have more fine-grained control for efficiency reasons, or to avoid dead-locks