dmd infers function closures impure if impure functions are defined within them.
even if those are never called and can never be accessed outside of the closure.

Example :

int a;
void closure() pure {
  impure_function() {
    a++;
   }
}
t.d(4): Error: pure function 't.closure.impure_function' cannot access mutable static data 'a'

is this intended ?

On Sun, 22 Mar 2015 12:58:23 +0000, Stefan Koch wrote:

> dmd infers function closures impure if impure functions are defined
> within them.
> even if those are never called and can never be accessed outside of the
> closure.
> 
> Example :
> 
> int a;
> void closure() pure {
>    impure_function() {
>      a++;
>     }
> }
> t.d(4): Error: pure function 't.closure.impure_function' cannot access
> mutable static data 'a'
> 
> is this intended ?

i think it is. you can't do anything with `impure_function` anyway.

On Sunday, 22 March 2015 at 18:24:31 UTC, ketmar wrote:

> you can't do anything with `impure_function` anyway.

Precisely my point!
a perfectly pure function is inferred impure because of dead code!

On Sun, 22 Mar 2015 18:44:47 +0000, Stefan Koch wrote:

> On Sunday, 22 March 2015 at 18:24:31 UTC, ketmar wrote:
> 
>> you can't do anything with `impure_function` anyway.
> 
> Precisely my point!
> a perfectly pure function is inferred impure because of dead code!

hm. i missed this part (about dead code). compiler doesn't do "dead nested function removal" before semantic analysis, afair, and attribute inference is in semantic stage.

yet you can cheat compiler by turning `impure_function()` to template. attribute inference on templates are done when template is instantiated, and `impure_function()` is never instantiated.

On Sunday, 22 March 2015 at 19:06:33 UTC, ketmar wrote:
> hm. i missed this part (about dead code). compiler doesn't do "dead
> nested function removal" before semantic analysis, afair, and attribute
> inference is in semantic stage.
>
> yet you can cheat compiler by turning `impure_function()` to template.
> attribute inference on templates are done when template is instantiated,
> and `impure_function()` is never instantiated.

I am implementing pure for sdc.
The point is, I want to get it right.

On Sun, 22 Mar 2015 19:38:52 +0000, Stefan Koch wrote:

> On Sunday, 22 March 2015 at 19:06:33 UTC, ketmar wrote:
>> hm. i missed this part (about dead code). compiler doesn't do "dead nested function removal" before semantic analysis, afair, and attribute inference is in semantic stage.
>>
>> yet you can cheat compiler by turning `impure_function()` to template.
>> attribute inference on templates are done when template is
>> instantiated,
>> and `impure_function()` is never instantiated.
> 
> I am implementing pure for sdc.
> The point is, I want to get it right.

i believe that both ways is right (i.e. both generating error and not generating error).

On Sunday, 22 March 2015 at 21:21:59 UTC, ketmar wrote:
> i believe that both ways is right (i.e. both generating error and not
> generating error).

I am sorry but, this is not an helpful answer.
I will stick to my callgraph analysis for now.

On Sunday, 22 March 2015 at 12:58:25 UTC, Stefan Koch wrote:
> dmd infers function closures impure if impure functions are defined within them.
> even if those are never called and can never be accessed outside of the closure.
>
> Example :
>
> int a;
> void closure() pure {
>   impure_function() {
>     a++;
>    }
> }
> t.d(4): Error: pure function 't.closure.impure_function' cannot access mutable static data 'a'
>
> is this intended ?

I think this was not intended and is simply a side effect of limited D call graph analysis. Relaxing that limitation makes sense to me because unused impure function can be used for compile-time reflection or returned from pure function as a result (you need to ensure it does not capture pure functions as closure context in that case)

On Monday, 23 March 2015 at 09:45:41 UTC, Dicebot wrote:

> I think this was not intended and is simply a side effect of limited D call graph analysis. Relaxing that limitation makes sense to me because unused impure function can be used for compile-time reflection or returned from pure function as a result (you need to ensure it does not capture pure functions as closure context in that case)

Yeah that was my guess as well.

On 2015-03-23 09:45:39 +0000, Dicebot said:

> I think this was not intended and is simply a side effect of limited D call graph analysis. Relaxing that limitation makes sense to me because unused impure function can be used for compile-time reflection or returned from pure function as a result (you need to ensure it does not capture pure functions as closure context in that case)

Pure functions returning impure functions.  *BOOM* My brain just exploded.

-Shammah