Walter Bright <> changed:

           What    |Removed                     |Added
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID

--- Comment #6 from Walter Bright <> 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,


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:
------- You are receiving this mail because: -------

Reply via email to