Bug 9853 – The order of static and shared on module constructors matters when it shouldn't

This code static shared this() { } void main() { } fails to compile, giving this error: q.d(1): Error: constructor q.this constructors are only for class or struct definitions whereas if the static and shared are swapped, it compiles just fine. The order shouldn't matter.

This is by design. http://dlang.org/class.html#StaticConstructor > The **static** in the static constructor declaration is not an attribute, > it must appear immediately before the this: > > class Foo { > static this() { ... } // a static constructor > static private this() { ... } // not a static constructor > static { > this() { ... } // not a static constructor > } > static: > this() { ... } // not a static constructor > }

Well, that seems incredibly arbitrary, and I have no idea how anyone could claim that static isn't an attribute. It's as much an attribute as const or shared is.

(In reply to comment #2) > Well, that seems incredibly arbitrary, and I have no idea how anyone could > claim that static isn't an attribute. It's as much an attribute as const or > shared is. I think that the limitation comes from current D parser. Current D parser does not distinguish `static: void foo(){}` and `static void foo(){}`. struct S { pure void foo() {} } is parsed as: struct S { pure { void foo() {} } } There is no "prefixed attribute". But, for static constructor, applying same mechanism is dangerous. struct S { static { this() {} // accidentally makes static constructor. } } I think that is why special rule exists for static constructor. --- Similar problem is in prefixed const and member function. struct S { const int foo() {} // const method foo, returns mutable int const: int bar() {} // const method bar, returns mutable int }