Sharing in D

[superdan]

Steven Schveighoffer Wrote:

> "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.

but the code there *is* different. there are fence combinations & shit. i guess in such cases you'd need a template.

> 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.

sounds interesting but i don't get it. we have:

invariant == never changes
const == i won't change it
mutable == fuck you, i'm changing

in the shared cases we have:

unshared == never seen by 2 threads
? == ?
shared == fuck you, i'm shared

so how would that go. i won't share it? i won't write to it? (that's useless bc of read fences.) anyway this is intriguing shit. unification is power.