Against enforce()

[Steven Schveighoffer]

On Fri, 18 Mar 2011 04:34:54 -0400, Don <nospam at nospam.com> wrote:

>> Steven Schveighoffer Wrote:
>>
>>> As long as the delegate does not access shared/global data, it should  
>>> be  able to be pure.  Even delegates which modify TLS data should be  
>>> able to  be pure (weak-pure, but still pure).
>
> TLS variables are global and must not be accessed from any function  
> marked as pure. With regard to purity, there isn't any difference  
> between shared and TLS variables.

However, it's still not shared.

This, for example, is a weak pure function:


void foo(int *n) pure { *n = 5;}

Because TLS variables are not shared, you should be able to do this:

int x;

void bar()
{
   foo(&x);
}

But you are right, there is a huge difference between a local reference to  
TLS data and directly accessing TLS data -- the latter can be obscured  
 from the compiler, resulting in the compiler thinking the function can be  
strong pure.

So I don't know exactly how to mitigate this, but in my mind, it feels  
like this should work:

int foo(bool cond, lazy int n) pure { if(cond) return n; return 0;}

int x;

void bar()
{
    foo(x == 4, x = 5);
}

It seems not too different from the above example where you pass the  
address of x.  But obviously the x = 5 delegate cannot be pure (it  
modifies TLS data).

We may have no recourse to get this to work.  It may be a lost cause, and  
you just can't have lazy variables for pure functions.

Cue the request for macros where you can just rewrite the syntax vs.  
having to use lazy in the first place...

-Steve