Struggling to implement parallel foreach...

Timon Gehr timon.gehr at gmx.ch
Fri Jun 14 22:31:32 UTC 2019


On 14.06.19 20:51, Manu wrote:
> On Fri, Jun 14, 2019 at 8:05 AM Kagamin via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>>
>> On Friday, 14 June 2019 at 09:04:42 UTC, Manu wrote:
>>> Right, exactly... the compile error should be at the assignment
>>> of the
>>> not-shared closure to the shared delegate. The error would be
>>> something like "can't assign `Context*` to `shared(Context)*`".
>>> So, the function can certainly exist, but for shared, you
>>> should get
>>> an error when you attempt to call it passing the closure to the
>>> function.
>>
>> The shared function attribute means that its context is shared
>> similar to object methods, the error is an attempt to implicitly
>> leak unshared data into that shared context, that's why indeed
>> function itself is incorrect. Declare the variable as shared and
>> it will work.
> 
> No, you've misunderstood. The qualifier does NOT apply to the context
> as it should, that's the issue I'm reporting.

There is a bug, but It appears you don't understand what it is. Why do 
you insist on reporting the bug in a particular wrong way instead of 
trying to understand what is actually going on?

This is not the first time you do this. Sometimes, you spend some time 
on your own to form some partially-correct opinion and then you stick to 
it against all evidence to the contrary.

> Try it with const, it's simpler to understand.

That's because it's a completely different case.

> You can incorrectly
> mutate x from a const context.
> 
> A local function is essentially:
> void localFun(Context*, Args...);
> 
> A const local function should be:
> void localFun(const(Context)*, Args...) const  // <- const applies to
> the context pointer, as usual.
> ...

Yes, but this is not "as usual". In particular, this is not how it works 
for `immutable` and `shared`, because it makes no sense. With your 
suggestion it would be impossible to ever call an `immutable` or 
`shared` local function unless all data that is transitively reachable 
from the current stack frame is `immutable` or `shared`, respectively. 
That's clearly useless.

> That does not appear to be the case however.
> For example:
> 
> void test()
> {
>    int x;
>    void fun() const
>    {
>      pragma(msg, typeof(x)); // should print `const(int)` because
> typeof(const(Context*).x) == const(int), but it incorrectly prints
> `int`
>      ++x; // <- should be an error, but the context pointer is not
> const, so this compiles!
>    }
> }
> 
> The context pointer is missing the qualifier.
> 

Yes, in this instance, but your actual blocker is that there is no 
`shared` inference for local functions.


More information about the Digitalmars-d mailing list