Hans;<br><br>&gt; That is my worry, too: lack of intuition. It invites errors.<br><br><br>I agree. The current behaviour is predictable, it could be called &quot;expected&quot; but I don&#39;t feel it&#39;s intuitive and I agree that it invites error. It&#39;s currently on the bugs page though it should probably be on a &quot;open for debate and better suggestions&quot; page instead.<br>
<br>I feel there is a issue here but I&#39;m not sure I have a alternative. We could have -for example- have a parser warning at this. We could also simply have attempts at setting values at definitions of static members result in a error or we could make a exception and set the value at defining the class itself. Then again; what if it&#39;s not a int being set as in;<br>
<br>3 =&gt; static int foo;<br><br> but a function-call returning a int? This;<br><br>my_fun() =&gt; static int bar;<br><br>might have side effects that could be quit far-ranging.<br><br>I think that if it were my call I&#39;d suggest leaving this be and dealing with it once we get &#39;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.<br>
<br>Yours,<br>Kas.<br>