Bug 3965 – Multiple "static this()" can be a little error-prone

This is inspired by the "Initialization diffusion" part of article "Coping with Java Programming Stress": http://www.cs.colostate.edu/~rta/publications/Computer00.pdf >initialization code is distributed between constructors and initialization blocks, which can be distributed throughout a class. Thus, to understand the full instance initialization and construction process, you must understand the semantics of constructors and instance initialization blocks. This means scanning an entire class definition looking for instance initializers, analyzing the semantics of each initializer and its order of execution, and then analyzing the class construction methods' semantics. This process is tedious and error-prone when you have many instance initializer blocks.< This is a D example: int a, b; static this() { a = 10; } class Foo { static this() { Foo.x = 10; } static int x, y; static this() { Foo.y = 20; } } static this() { b = 10; } void main() {} To avoid that small problem D can allow only one "static this()" for each class (and maybe allow only one global static this in a module. But in my opinion estricting only one module static constructor is less important than restricting to one the static costructor of classes). So only this is allowed: int a, b; static this() { a = 10; b = 10; } class Foo { static this() { Foo.x = 10; Foo.y = 20; } static int x, y; } void main() {}

If you followed the latest discussion on static constructors on the Newsgroup you would see, that it's often required to mix in static constructors to support library code. Your proposal renders it impossible.

That's true, I also use that.

I believe this is a valuable feature for D. Sure, you can write convoluted code with it, but so you can in general with any programming construct. Forcing it all into one static constructor can also be confusing, because it takes away locality of operations, which can cause its own confusion. Won't implement.