http://d.puremagic.com/issues/show_bug.cgi?id=7868
Walter Bright <bugzi...@digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID --- Comment #6 from Walter Bright <bugzi...@digitalmars.com> 2012-04-09 16:30:09 PDT --- Ok, here's what's happening (took me a couple hours). As you said, is(B!C) is relying on the eponymous name trick. The eponymous name trick relies on knowing the names of all the members of a template. So, is(B!C) cannot resolve to an eponymous name until all the members are resolved. But inside B(T), we have an __traits(derivedMembers, C). Now, in order to produce all of the members, it has to determine all the members. But some of those members are inside a static if, which also relies on knowing all the members. Hence, it fails. And, it fails silently because it fails inside an 'is' expression, which gags errors. Why did this not fail on older versions? Because I recently fixed __traits(derivedMembers) to check for the member list being complete. There were multiple bugzilla entries that failed because it only looked at the member list that was in progress. The compiler tries hard to extract information wherever possible from incompletely analyzed types, but this one is just too much circular dependencies that I cannot figure any way out of. Try it yourself. Start with struct C and mentally follow the steps to do the semantic analysis. You'll go in a circle with no way out. Switching the is expression to __traits(compiles) works because it doesn't rely on the eponymous name trick. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------