On 25 Nov 2009, at 06:09, Kassen wrote:
Then again; what if it's not a int being set as in;
3 => static int foo;
but a function-call returning a int? This;
my_fun() => static int bar;
might have side effects that could be quit far-ranging.
I think that if it were my call I'd suggest leaving this be and dealing with it once we get 'round to constructors. It does have uses as it is; for one thing it can tell us whether this static member is a member of a class that has a instance at all, in convenient -if hackish- shorthand. Classes and instantiation have far worse issues than this, though indeed this particular behaviour could stand documentation.
I was thinking about that situation, too. There is are two concepts: the body of a class treated as code, which should be run when the class is initialized, and as a name space. If one wants to keep both, the problem is to find a good syntax for it. The class "static" functions are just name space localizations, and may call class "static" data. Therefore, it would be confusing to not having the latter initialized when the former are called. So some new syntax might be in place. Hans