Steven Schveighoffer wrote:
On Fri, 18 Mar 2011 04:34:54 -0400, Don <nos...@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);
}
Yes, that compiles fine. But bar() is not pure.
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.
It's not a lost cause, it's a two-liner!
mtype.c line 5045:
if (fparam->storageClass & STClazy)
{
- error(0, "cannot have lazy parameters to a pure
function");
+ tf->purity = PUREweak;
+ break;
}
This is a bit conservative: it would be possible to allow lazy
parameters to be marked as pure, which would allow them to be strongly
pure. But that would probably not be worth the extra complexity.