Sharing in D

[Jason House]

Steven Schveighoffer Wrote:

> "Jason House" wrote
> > Walter Bright Wrote:
> >
> >> Jason House wrote:
> >> > Walter Bright Wrote:
> >> >
> >> >> http://www.reddit.com/comments/6u7k0/sharing_in_d/
> >> >
> >> > This is one of my 3 big wishes for the D language.
> >> >
> >> > The artical talks about shared being transitive just like
> >> > const/invariant. I certainly hope it's more like pure than transitive
> >> > invariant.
> >>
> >> Pure doesn't apply to data types, it applies to functions. I don't know
> >> what you mean.
> >
> >
> > Let's say I have an object that was originally written assuming non-shared 
> > access and contains one member function with no arguments.  Some later 
> > coder comes by and decides it'd be nice to share this object among threads 
> > and creates a shared instance of it.
> >
> > There's no way to know if calling the member function is safe.  Maybe it 
> > accesses a non-shared global variable.  Maybe a call to an encapsulated 
> > object's member function uses a non-shared global variable.  The 
> > maintainer must be extremely careful and scour the code to ensure there's 
> > no accidental sharing that was not intended.
> >
> > Maybe I'm reading too much into stuff again, but the article did say "The 
> > proposal is to make accidental sharing impossible".
> 
> I have a feeling that the shared/unshared comes with a requriement for 
> 'shared' functions.  That is, in order to call a function on an object that 
> is 'shared', you have to call a function where the 'this' pointer is shared:
> 
> class C
> {
>    shared f(); // can call on a shared C instance, means the 'this' pointer 
> is shared
>    f(); // can call on an unshared C instance
> }
> 
> -Steve 
> 
> 

I'd much prefer to discuss the problematic use case and either confirming or rejecting that D will help protect against it.  Your definition implies that such programming errors will not be caught.  This seems against the spirit of the article.