Re: [Boost-users] [MPL] HAS_XXX gives the wrong answer after "enable_if" on incomplete type in GCC 4.6/7

Subject: Re: [Boost-users] [MPL] HAS_XXX gives the wrong answer after "enable_if" on incomplete type in GCC 4.6/7
From: Nathan Crookston (nathan.crookston_at_[hidden])
Date: 2012-12-19 12:27:58

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<traitor_1>::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