Sharing in D

[Walter Bright]

Steven Schveighoffer wrote:
> "Walter Bright" wrote
>> http://www.reddit.com/comments/6u7k0/sharing_in_d/
> 
> There are 2 problems I see with this scheme.
> 
> First, that the default is 'unshared'.  This is going to break a lot of 
> existing code, and make peoples lives miserable who do not want to deal with 
> unshared non-stack data.

Nearly all global data is assumed to be and treated as if it were 
unshared. So making unshared the default is the right solution. And 
frankly, if you're using a lot of global variables, you might want to 
reevaluate what you're doing. Lots of global variables is the 80's style 
of programming :-)

> I would hazard to guess that adopting this would 
> cause a larger rift than const.

Perhaps. But the alternative is the current wild west approach to 
multithreaded programming. With the proliferation of multicore 
computers, the era where this is acceptable is coming to an end.

> Second, the fact that you can't implicitly cast shared to unshared and vice 
> versa.  It's going to make communication between both 'worlds' very error 
> prone, as you will be required to cast for any call from one to the other.

I think the reverse is true. Moving data between those worlds is 
dangerous and needs to be carefully vetted, so requiring an explicit 
cast will reduce the chance of this happening unintentionally.


> People will do this just to get their code to work, without thinking about 
> the consequences.

True, but having it happen implicitly is even worse, because there's no 
indication that it is happening.

> Even those that do think about the consequences, can't 
> have the compiler statically check the cast in either direction, so once you 
> cast, you lose all the benefit.

But still, you're far better off than the current wild west approach 
where everything is implicitly shared with no protection whatsoever. The 
popular double checked locking bug will be impossible to code in D 
without stuffing in explicit casts. The casts will be a red flag that 
the programmer is making a mistake.

> I'd have to see solutions to these before I'd think it was a good idea.  Or 
> else examples of how to avoid these problems.