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: Duncan Exon Smith (duncanphilipnorman_at_[hidden])
Date: 2012-12-19 09:22:15

On 18/12/2012, Nathan Ridge <zeratul976_at_[hidden]> 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...

Most interesting to me is that using "enable_if<has_trait<T>>" changes
the final value of "has_trait<T>" by observing it "too early"...