Thread overview
Static constructors inconsistency
Apr 26, 2014
spec
Apr 26, 2014
spec
Apr 27, 2014
Ali Çehreli
Apr 27, 2014
spec
Apr 27, 2014
bearophile
Apr 27, 2014
bearophile
Apr 27, 2014
spec
Apr 27, 2014
bearophile
Apr 27, 2014
bearophile
April 26, 2014
Hello, i'am experiencing some non consistent behavior with static constructors. I wonder if this is some bug or i just don't know enough of D (most probably!).. Code example bellow:

//------------------------------------------
module main;

import std.stdio;

class B
{
	static this()
	{
		A a = new A;
		int val = a.getValue("A");
	}
}

class A {
	private static int[string] aa;
	
	static this()
	{
		aa = ["A":1, "B":2];
		writeln("@ A static ctor!");
	}

	int getValue(string str)
	{ 	
		return aa[str];	
	}
}



void main(string[] args)
{
	B B = new B;
}
//------------------------------------------

The text "@ A static ctor!" never gets printed. The inconsistency (IMHO) is that if i do any of this:
- Declare class A before B;
- Change the var declared in A from an AA to some other p.e int;
- Comment the line "int val = a.getValue("A")";

Maybe there are some other points, but at this point i got confused and decided trying to understand it. Anyway with any of those changes the text gets printed.

Anyone able to shed some light into this?

Cheers,
April 26, 2014
Btw, i only tested this using v2.065.0 of DMD.

Cheers,

April 27, 2014
On 04/26/2014 12:10 PM, spec wrote:

> Hello, i'am experiencing some non consistent behavior with static
> constructors. I wonder if this is some bug or i just don't know enough
> of D (most probably!).. Code example bellow:
>
> //------------------------------------------
> module main;
>
> import std.stdio;
>
> class B
> {
>      static this()
>      {
>          A a = new A;
>          int val = a.getValue("A");
>      }
> }
>
> class A {
>      private static int[string] aa;
>
>      static this()
>      {
>          aa = ["A":1, "B":2];
>          writeln("@ A static ctor!");
>      }
>
>      int getValue(string str)
>      {
>          return aa[str];
>      }
> }
>
>
>
> void main(string[] args)
> {
>      B B = new B;
> }
> //------------------------------------------
>
> The text "@ A static ctor!" never gets printed. The inconsistency (IMHO)
> is that if i do any of this:
> - Declare class A before B;
> - Change the var declared in A from an AA to some other p.e int;
> - Comment the line "int val = a.getValue("A")";
>
> Maybe there are some other points, but at this point i got confused and
> decided trying to understand it. Anyway with any of those changes the
> text gets printed.
>
> Anyone able to shed some light into this?
>
> Cheers,

I don't know whether the inconsistency is a bug but according to documentation, static this inside a module are executed in lexical order: "Static constructors within a module are executed in the lexical order in which they appear."

  http://dlang.org/class.html#StaticConstructor

So, if B depends on A then A's static this must appear before B's.

Ali

April 27, 2014
On Sunday, 27 April 2014 at 02:06:14 UTC, Ali Çehreli wrote:

> I don't know whether the inconsistency is a bug but according to documentation, static this inside a module are executed in lexical order: "Static constructors within a module are executed in the lexical order in which they appear."
>
>   http://dlang.org/class.html#StaticConstructor
>
> So, if B depends on A then A's static this must appear before B's.
>
> Ali

Arghh i hate when i make a mistake because i missed something on the docs, mainly when i actually read them. Thanks Ali.

Although, yeah, it would be nice if the compiler emitted some kind of warning pointing this (if it's at all possible). What got me confused was indeed the disparity of results from changing small things.

Cheers,
April 27, 2014
spec:

> Although, yeah, it would be nice if the compiler emitted some kind of warning pointing this (if it's at all possible). What got me confused was indeed the disparity of results from changing small things.

If you think this can be done and it's useful, then ask for this enhancement request in Bugzilla.

Bye,
bearophile
April 27, 2014
spec:

> Although, yeah, it would be nice if the compiler emitted some kind of warning pointing this (if it's at all possible). What got me confused was indeed the disparity of results from changing small things.


D doesn't like warnings, but it could be an error. This is minimized code:


struct Foo {
    static this() {
        Bar b;
        int x = b.data[0];
    }
}
struct Bar {
    static int[] data;
    static this() {
        data.length++;
    }
}
void main() {}


A similar example:

struct Foo {
    static this() {
        Bar b;
        int x = b.data[0];
    }
}
struct Bar {
    immutable static int[] data;
    static this() {
        data.length++;
    }
}
void main() {}



Is it possible and a good idea to raise a compilation error in such cases where code tries to use Bar static fields before bar static this() has run? (But perhaps a more fine-grained error is needed, that tracks single fields, to allow more flexible code of mutually initializing constructors).

Bye,
bearophile
April 27, 2014
On Sunday, 27 April 2014 at 13:31:39 UTC, bearophile wrote:
> Is it possible and a good idea to raise a compilation error in such cases where code tries to use Bar static fields before bar static this() has run? (But perhaps a more fine-grained error is needed, that tracks single fields, to allow more flexible code of mutually initializing constructors).
>
> Bye,
> bearophile

I usually try to refrain myself from opinionating on stuff where i lack proper knowledge and i'am still a newbie with D (contrary to you bearophile). Having said this, the current behavior did confused me and it may very well confuse others in the future. I would very much prefer that an error had been thrown, because at that point, i would know immediately that it was me who was doing something wrong..

Cheers,
April 27, 2014
spec:

> I usually try to refrain myself from opinionating on stuff where i lack proper knowledge and i'am still a newbie with D (contrary to you bearophile).

It's not just a matter of experience, when there are many interacting parts it's also a matter of intelligence (and people like Timon are more intelligent than me regardless my experience in D). If no one comment I'll put this in Bugzilla.

Bye,
bearophile
April 27, 2014
> If no one comment I'll put this in Bugzilla.

https://issues.dlang.org/show_bug.cgi?id=12667

Bye,
bearophile