Can we drop static struct initializers?

Don nospam at nospam.com
Fri Nov 20 21:58:56 PST 2009


Walter Bright wrote:
> Bill Baxter wrote:
>> On Fri, Nov 20, 2009 at 4:05 PM, Walter Bright
>> <newshound1 at digitalmars.com> wrote:
>>> Bill Baxter wrote:
>>>> Right, but if you do define it (in order to do something extra upon
>>>> initialization -- validate inputs or what have you) then it no longer
>>>> works at compile time.
>>> Right, but the static initialization then shouldn't work, either.
>>
>> Why not?  It works if you use static opCall(int,int) instead of 
>> this(int,int).
> 
> Because if you need runtime execution to initialize, a back door to 
> statically initialize it looks like a bug.

No, it's a known bug. The problem is that a constructor call A a(b); 
gets changed into   (A __a;, __a.opThis())

The scope of __a is whereever it's called from. In the case of

const int X = foo(A a);

__ is in global scope, so it's a static variable, and therefore can't be 
used in CTFE! But of course it's not a genuine static, it's just an 
artifact of the transformation.

Exactly the same problem happens with variadic arguments. And for pretty 
much the same reason, you get an ICE if you declare a struct with a 
constructor as a default function parameter.
I'm not sure, but it could be that int parameters also become shared 
variables?

One way to fix it might be to introduce a flag such that 
compiler-generated statics are marked so that they can distinguished 
from real statics.



More information about the Digitalmars-d mailing list