> On Fri, 22 Jul 2011 02:57:38 -0400, Diego Canuhé <canuhedc@gmail.com>
> 
> wrote:
> > thanks ;)
> 
> Don't feel bad, static is probably the most abused keyword in D and C++. It has about 3 or 4 meanings depending on context.

The interesting thing is that in C++, there's actually a definition for static which covers _all_ of its uses. Unfortunately, at the moment, I can't remember it exactly (something about global lifetime and limited scoped, I think). But with the change to thread-local as the default in D and the addition of static constructors and what static does to nested classes and functions, I don't think that that definition applies to D. It was a relatively useless definition anyway, since you really need to know in detail how static works in each case rather than have a definition which is vague enough to cover a variety of cases which most anyone would consider completely unrelated. It was pretty cool though that there was a definition which covered all of the cases. I just wish that I could remember what it was...

- Jonathan M Davis

Filed with a simplified test case: http://d.puremagic.com/issues/show_bug.cgi?id=6364

On Saturday 23 July 2011 08:52:28 Andrej Mitrovic wrote:
> What are the current semantics of static struct definitions in module scope? It doesn't seem to have any effect. I was thinking about this:
> 
> module test;
> 
> int z;
> 
> static struct Foo
> {
>     void foo()
>     {
>         z = 5;  // maybe make this an error if the struct definition is
> static? }
> }
> 
> Maybe it could be useful as protection against modifying globals.

static only affects what can be accessed when it's on something that's nested. It affects member functions (which are nested in a class or struct), making it so that it can't access the surrounding class or struct. The same goes with nested structs and classes. When used on a function, struct, or class inside of a function, it makes it so that that nested function, struct, or class cannot access the scope of the function that it's in. It _never_ has any effect on global variables, and it _never_ affects _anything_ at module scope.

The struct above isn't nested in anything, so static makes no sense for it. And if you tried to make it so that it so that its functions then couldn't acces the module's scope, that would be completely inconsistent with everything else. The only time that a function cannot access a variable at module scope is when that function is pure. You're essentially suggesting that static be used to do pure's job in this case.

- Jonathan M Davis

Ok, so pure does the job, didn't know.

On Saturday 23 July 2011 11:28:07 Andrej Mitrovic wrote:
> Ok, so pure does the job, didn't know.

There are two requirements for a function to be pure:

1. Any functions that it calls must be pure.

2. It cannot access any static or global variables unless they're immutable or they're const value types (essentially, they can't access any static or global variables which could ever be changed over the course of the program).

So, if a function is pure, it can't access a global variable like in your example. Now, in addition to that, if a pure function's arguments can be determined to be guaranteed to be unchanged when the function is call, then that function is strongly pure, and additional calls to it with the same arguments in the same expression can be optimized out. At the moment, that means that the function's parameters must all either be immutable or implicitly convertible to mutable, but there are cases where the compiler could conceivably optimize it with just const (e.g. if an immutable variable is passed to a function where the parameter is const).

So, the primary thing that you get out of pure in the general case (since so many functions can be weakly pure but not strongly pure) is that you have the guarantee that it doesn't access global variables whose state is at all mutable.

- Jonathan M Davis