http://d.puremagic.com/issues/show_bug.cgi?id=4595
--- Comment #14 from Kenji Hara <k.hara...@gmail.com> 2013-09-19 00:33:55 PDT --- (In reply to comment #13) > After a few years of D use, I actually find the above will create problems. We > often use traits like these to check whether something is compilable, even if > the object is left uninitialized. Today, code flow analysis for class ctor call (super(...) and this(...)) behaves as follows. class Foo { this(int) {} } class Bar : Foo { this() { static assert(is(typeof(super(0)))); static if (is(typeof(super(0)))) {} // inside typeof(), code flow analysis never works. super(1); // OK static assert(is(typeof(super(0)))); static if (is(typeof(super(0)))) {} // also OK super(2); // Error: multiple constructor call } this(int) { static assert( __traits(compiles, super(1))); // inside __traits(compiles), code flow analysis is enabled. super(1); // Error: multiple constructor call static assert(!__traits(compiles, super(2))); // The _second_ super call makes error. super(3); // Error: multiple constructor call } } This is expected behavior, from my compiler-internal knowledge. - `is(typeof(exp))` tests that the exp has valid type or not. For type calculation, the code flow analysis and its validation result is just unnecessary. - `__traits(compiles, exp)` tests the exact validness of `exp` at there. In other words, `__traits(compiles)` converts the error occurrence on the `exp` semantic analysis to the compile-time boolean value. In there, code flow analysis is enabled, and the errors will be counted normally. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------