https://issues.dlang.org/show_bug.cgi?id=9148

--- Comment #12 from github-bugzilla@puremagic.com ---
Commit pushed to 2.067 at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/ec19b35a34a2780d03d2652c068ebe2995d2905e fix 9148 - Issue 9148 - 'pure' is broken

--

https://issues.dlang.org/show_bug.cgi?id=9148

--- Comment #13 from Kenji Hara <k.hara.pg@gmail.com> ---
*** Issue 7457 has been marked as a duplicate of this issue. ***

--

https://issues.dlang.org/show_bug.cgi?id=9148

--- Comment #14 from Kenji Hara <k.hara.pg@gmail.com> ---
*** Issue 10614 has been marked as a duplicate of this issue. ***

--

https://issues.dlang.org/show_bug.cgi?id=9148

--- Comment #15 from Kenji Hara <k.hara.pg@gmail.com> ---
*** Issue 11412 has been marked as a duplicate of this issue. ***

--

https://issues.dlang.org/show_bug.cgi?id=9148

--- Comment #16 from timon.gehr@gmx.ch ---
(In reply to Kenji Hara from comment #11)
> I'm adjusting the implicit pure annotation behavior for nested functions in: https://github.com/D-Programming-Language/dmd/pull/4344
> 
> If the nested function is a template, attribute inference is preferred and pure will be added only when the function is accessing enclosing pure function context.
> 
> auto foo() pure {
>     int x;
>     auto bar()() {   // template function bar can be impure by default
>         // bar will be forced to get weak purity, only when it's trying
>         // to access enclosing pure function context.
>         //x = 1;
> 
>         // otherwise, bar can call impure functions and then
>         // it will be inferred to impure.
>         impureFuncCall().
>     }
> }
> 
> Once nested template function is inferred to impure, it cannot access enclosing pure context anymore.
> 
> auto foo() pure {
>     int x;
>     auto bar()() {
>         impureFuncCall().
>         x = 1;  // Error: impure function 'bar' cannot access variable 'x'
>                 // declared in enclosing pure function 'foo'
>     }
> }

I think this is not right. Why should impure nested functions not be able to access the enclosing context corresponding to frames of pure functions?

--

https://issues.dlang.org/show_bug.cgi?id=9148

--- Comment #17 from Kenji Hara <k.hara.pg@gmail.com> ---
(In reply to timon.gehr from comment #16)
> I think this is not right. Why should impure nested functions not be able to access the enclosing context corresponding to frames of pure functions?

Because the nested impure function may modify the context of other pure functions.

int g;
int impureFuncCall() { return g; }

auto func(out int delegate() pure pureDg, out void delegate() impureDg) pure
{
    int x = 1;      // become a closure variable

    int foo() pure  // weak purity
    {
        return x;
    }

    auto bar()()
    {
        // modify the context of pure funciton 'foo'
        // depending on the global state,
        if (impureFuncCall())
            x = 2;      // !!
    }

    pureDg = &foo;
    impureDg = &bar!();
}

void main()
{
    int delegate() pure pureDg;
    void delegate() impureDg;

    func(pureDg, impureDg);

    assert(pureDg() == 1);

    g = 1;  // modify the global state
    impureDg(); // modify the context of pureDg.

    assert(pureDg() == 1);  // fails~
}

--

https://issues.dlang.org/show_bug.cgi?id=9148

--- Comment #18 from timon.gehr@gmx.ch ---
(In reply to Kenji Hara from comment #17)
> (In reply to timon.gehr from comment #16)
> > I think this is not right. Why should impure nested functions not be able to access the enclosing context corresponding to frames of pure functions?
> 
> Because the nested impure function may modify the context of other pure functions.
> 
> int g;
> int impureFuncCall() { return g; }
> 
> auto func(out int delegate() pure pureDg, out void delegate() impureDg) pure
> {
>     int x = 1;      // become a closure variable
> 
>     int foo() pure  // weak purity
>     {
>         return x;
>     }
> 
>     auto bar()()
>     {
>         // modify the context of pure funciton 'foo'
>         // depending on the global state,
>         if (impureFuncCall())
>             x = 2;      // !!
>     }
> 
>     pureDg = &foo;
>     impureDg = &bar!();
> }
> 
> void main()
> {
>     int delegate() pure pureDg;
>     void delegate() impureDg;
> 
>     func(pureDg, impureDg);
> 
>     assert(pureDg() == 1);
> 
>     g = 1;  // modify the global state
>     impureDg(); // modify the context of pureDg.
> 
>     assert(pureDg() == 1);  // fails~
> }

I understand. My question was why you consider this to be a _problem_. pureDg is weakly pure. I can change the context of a weakly pure delegate depending on global state in other ways if I want to.

--

https://issues.dlang.org/show_bug.cgi?id=9148

--- Comment #19 from Kenji Hara <k.hara.pg@gmail.com> ---
(In reply to timon.gehr from comment #18)
> I understand. My question was why you consider this to be a _problem_. pureDg is weakly pure. I can change the context of a weakly pure delegate depending on global state in other ways if I want to.

I thought it would violate the purity concept in D.

--

https://issues.dlang.org/show_bug.cgi?id=9148

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com

--- Comment #20 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Kenji Hara from comment #19)
> (In reply to timon.gehr from comment #18)
> > I understand. My question was why you consider this to be a _problem_. pureDg is weakly pure. I can change the context of a weakly pure delegate depending on global state in other ways if I want to.
> 
> I thought it would violate the purity concept in D.

I agree with Timon. It's not that much different from a class with two member functions, one pure and one not pure.

--

https://issues.dlang.org/show_bug.cgi?id=9148

--- Comment #21 from Kenji Hara <k.hara.pg@gmail.com> ---
> It's not that much different from a class with two
> member functions, one pure and one not pure.

Oh, it sounds very reasonable. Could you please open a new issue to fix the current unnecessarily tight behavior?

--