Semantics of shared

[Jason House]

Matt Wrote:

> Jason House Wrote:
> 
> > Matt Wrote:
> > > Is this about right?
> > 
> > I don't think so. What happens when the lock is released? Any residual use of the cast data is going to be incorrect (lacks a lock). What that means is that the cast is unsafe even when the data is locked! Casting is a back door that should be used with extreme care.
> 
> You're right - it's a big departure from C++ where casting is to be avoided if possible, and you're right that the cast isn't safe in general.  It's semi-reasonable because it's safe unless you cast somewhere and the C++ multi-threaded programming model is unsafe anyway.  But it's bad that the bugs introduced can be quite far from the casts (e.g. if cast-to-unshared data is placed in a global thread-local somewhere).
> 
> But I don't see how you can do much of anything useful with shared data if something like this isn't the plan.  Tracking what data is protected by lock and when is going to be outside of the scope of any type system you're going to want for D (and is going to be undecidable in general).
> 

We're all still waiting to hear how D will handle locking under the covers. I don't think locking will be used to change types. A shared variable will always be shares, even if you have the lock.