http://d.puremagic.com/issues/show_bug.cgi?id=3965
Summary: Multiple "static this()" can be a little error-prone Product: D Version: 2.041 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2010-03-15 08:58:51 PDT --- 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() {} -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------