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