Sharing in D

[Steven Schveighoffer]

"Sean Kelly" wrote
> == Quote from Steven Schveighoffer article
>> "Walter Bright" wrote
>> > Steven Schveighoffer wrote:
>> >> "Walter Bright" wrote
>> >>> 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 have no idea where you came up with this.  To me global means 
>> >> shared.
>> >> Global means the world can see it, meaning that it's shared between 
>> >> all.
>> >> Even VB.net uses 'Shared' as the keyword to mean 'global'
>> >
>> > The idea is that encapsulation is better, and having something shared
>> > between everyone violates encapsulation. When you have a global 
>> > variable
>> > 'int x' that everyone can read and write to, and there's a bug, you 
>> > have
>> > the whole program to search for that bug. The principle of 
>> > encapsulation
>> > is that each chunk of data is visible only to the code that needs to 
>> > see
>> > it, and no more.
>> So if I write:
>> shared int x;
>> As a global variable, how does this help encapsulation?  In the current
>> model, if you need shared data, you use global variables.  If you don't 
>> need
>> shared data, use member or stack variables.  My point is that what you 
>> will
>> have done is just made the person who wants a global variable write 
>> 'shared'
>> in front of it.  I don't see how this helps him protect the variable at 
>> all.
>> It just seems like you are enforcing something that already can be 
>> enforced.
>> > (Programming languages started out with everything being global data, 
>> > and
>> > has moved away from that ever since.)
>> I'm not advocating using global variables over stack or member variables.
>> All I'm saying is that this 'shared/unshared' model doesn't seem to me 
>> like
>> it will eliminate the need for threading constructs, or even help with 
>> it.
>
> I'm hoping that 'shared' will force programmers to think about what 
> they're
> doing a bit more.  A typical multithreaded app should have extremely 
> little
> shared data.  One thing I'm not sure of, though, is if I write a single-
> threaded app, will I need to label anything shared?  Functionally I don't,
> since having everything thread-local is exactly what I need, but I'm not
> sure if the compiler will yell at me anyway.  I'm guessing it will, which
> would be a bit annoying, but it would "future proof" the app for adding
> multithreading later, so perhaps it's okay.

I'm thinking more in the case of functions.  If I have a function foo, and I 
want to pass my shared data version to it, I need to re-implement foo with 
the parameters as being shared.  Imagine a function with several parameters, 
in which you want to pass a combination of shared/unshared.  That's 2^n 
variations you have to write.

I think at the very least, for this to be palatable, there needs to be 
another modifier that unifies shared and unshared.  Similar to how const 
unifies mutable and invariant.

-Steve