• bearophile (11/11) Oct 28 2011 What do you think about a rewrite rule that changes code like:
• Nick Sabalausky (7/16) Oct 28 2011 You generally need to be very careful about adding module/static ctors,
• bearophile (4/7) Oct 28 2011 I see. Thank you for your answer.
• bearophile (13/18) Oct 29 2011 Second try. What about the lowering of:
• Jonathan M Davis (18/42) Oct 29 2011 No. The presence of any static constructors of any kind within a module ...
• sergk (23/32) Nov 09 2011 Its not quite same case, but still could be useful - what I usually do

bearophile <bearophileHUGS lycos.com> writes:

What do you think about a rewrite rule that changes code like:

int[int] aa = [1:2, 3:4];
void main() {}


Into:

int[int] aa;
static this() {
    aa = [1:2, 3:4];
}
void main() {}

Bye,
bearophile

"Nick Sabalausky" <a a.a> writes:

"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:j8eflp$q3o$1 digitalmars.com...
 What do you think about a rewrite rule that changes code like:

 int[int] aa = [1:2, 3:4];
 void main() {}


 Into:

 int[int] aa;
 static this() {
    aa = [1:2, 3:4];
 }
 void main() {}

You generally need to be very careful about adding module/static ctors, 
because they can easily lead to the dreaded circular ctor runtime error. So 
as nice as it would be to use AA initializers at the module-level, this 
carries a hidden danger which could be a royal PITA to debug (especially for 
D newbies), so I don't think it's a good thing to do.

bearophile <bearophileHUGS lycos.com> writes:

Nick Sabalausky:

 So as nice as it would be to use AA initializers at the module-level, this 
 carries a hidden danger which could be a royal PITA to debug (especially for 
 D newbies), so I don't think it's a good thing to do.

I see. Thank you for your answer.

Bye,
bearophile

bearophile <bearophileHUGS lycos.com> writes:

Nick Sabalausky:

 You generally need to be very careful about adding module/static ctors, 
 because they can easily lead to the dreaded circular ctor runtime error. So 
 as nice as it would be to use AA initializers at the module-level, this 
 carries a hidden danger which could be a royal PITA to debug (especially for 
 D newbies), so I don't think it's a good thing to do.

Second try. What about the lowering of:

int[int] aa = [1:2, 3:4];
void main() {}


To (now the static this generated for this initialization is enforced to be
pure):

int[int] aa;
pure static this() {
    aa = [1:2, 3:4];
}
void main() {}


Is this enough to avoid the problems you talk about?

Bye,
bearophile

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Saturday, October 29, 2011 05:20:35 bearophile wrote:
 Nick Sabalausky:
 You generally need to be very careful about adding module/static ctors,
 because they can easily lead to the dreaded circular ctor runtime error.
 So as nice as it would be to use AA initializers at the module-level,
 this carries a hidden danger which could be a royal PITA to debug
 (especially for D newbies), so I don't think it's a good thing to do.

 
 Second try. What about the lowering of:
 
 int[int] aa = [1:2, 3:4];
 void main() {}
 
 
 To (now the static this generated for this initialization is enforced to be
 pure):
 
 int[int] aa;
 pure static this() {
     aa = [1:2, 3:4];
 }
 void main() {}
 
 
 Is this enough to avoid the problems you talk about?

No. The presence of any static constructors of any kind within a module means 
that it runs the risk of a circular depencency. If it manages to import 
another module - directly or indirectly - which imports it, then your program 
will throw an exception and terminate at runtime when it starts up. The 
compiler cannot find such circular dependencies at compile time (I believe 
because it could depend on what's linked in), and the only way to fix the 
problem is to remove all of the static constructors in one of the modules. 
There are some modules in Phobos which have create C functions which do the 
job of static constructors and created separate, helper modules which call 
those functions in their module constructors in order to avoid a circular 
dependency. And that solution can't be done in cases where any of the 
variables being intialized are const or immutable. It's a problem which is all 
too easy to get into and a pain to fix. The issues with static constructors and 
circular dependencies is one of the roughest pieces of D IMHO. Unfortunately, 
no one has been able to come up with an acceptable means of fixing the problem. 
Doing _any_ kind of lowering to a static constructor is bad news.

- Jonathan M Davis

sergk <kovrov+puremagic gmail.com> writes:

On Fri, Oct 28, 2011 at 5:53 PM, bearophile <bearophileHUGS lycos.com> wrot=
e:
 What do you think about a rewrite rule that changes code like:

 int[int] aa =3D [1:2, 3:4];
 void main() {}


 Into:

 int[int] aa;
 static this() {
 =A0 =A0aa =3D [1:2, 3:4];
 }
 void main() {}

Its not quite same case, but still could be useful - what I usually do
if I need global or static immutable AA behavior:

int f_aa(int key)
{
    switch (key) {
    case 1: return 2;
    case 3: return 4;
    default: return int.init;
    }
}

void main()
{
    // f_aa =3D=3D [1:2, 3:4]
    static assert (f_aa(1) =3D=3D 2);
    static assert (f_aa(3) =3D=3D 4);
}


For immutable data or CTFE I cannot see other way to get AA-like data.
The function itself could be generated on compile-time as string
mixin, but I usually don't bother.


--=20
serg.