Struggling to implement parallel foreach...

[Manu]

On Thu, Jun 13, 2019 at 7:00 PM Timon Gehr via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 14.06.19 03:40, Manu wrote:
> > void test()
> > {
> >          int x;
> >          void fun() shared
> >          {
> >              x++; // <-- error here
> >          }
> >          fun();
> > }
> >
> > And I got this error:
> >
> > Error: `shared` function `test.fun` cannot access non-shared data `x`
> >
> > That looks like a bug.
>
> It's by design. It's not pretty that the qualifiers have a different
> meaning for member functions and nested functions (because the nested
> function meaning could be useful for member functions too), but it's
> what we have.

Okay. Well, that seems like bad design. Why is it that way? How do we fix this?
I've been working towards parallel foreach for like 18 months here, I
finally have all my ducks in a line, try and type the thing, and it
doesn't work...

> > `fun` is a delegate, and it's shared, which
> > means its `this` pointer is shared, which means `this.x` should be
> > shared... but that seems not to be the case.
> > ...
>
> There is no `this` pointer.

What do you mean? Local functions receive a context just like any
method... if it's attributed, then it should be attributed.

> For local functions, `shared` means that
> every variable accessed in the context is shared.

Not clear what you mean. It sounds like you suggest what I expect, but
that's not what I observe.
I expect that if the context is shared, then the transitive rule
applies normal. Everything accessed should be shared...?

> > I think this is a bug. The compile error should have been that I was
> > unable to call fun() with a non-shared delegate (since the calling
> > scope is not shared).
>
> There is no way to make the "calling scope shared".

Yes. So I expect the compile error I suggested?