Duncan Exon Smith wrote:
Nathan Ridge wrote:
I'm not sure which is the case either, but notice that a simple workaround is to define f after traitor_1 is complete (you can still *declare* f where you do now).
Yes, you are correct; my actual code is a fair bit more complicated, but there is definitely a workaround.
Moreover, to change this to a compile-time error, I'll change the definition of "traitor_1" to include a static assertion as follows.
struct traitor_1 { typedef void *trait; static_assert(has_trait
::value, "traitor_1::trait missing"); }; Without a static assertion failing, real code would compile with the wrong value for "has_trait<>". I think adding this to the definition will fix most of the otherwise "silent" bugs.
I'm still interested in whether this is a defect, or just a limitation of C++, if anyone has an opinion...
For what it's worth, I was surprised that has_trait didn't error out when passed an incomplete type. It seems like just having it return false with incomplete types would be problematic for more than just the incorrect deduction -- it could lead to ODR violations, etc. Perhaps the macros should have a sizeof(T) line added. . . Thanks, Nate