Unqualified std type trait use? about type_traits

[uecasm]

Perhaps the intent is to use the boost traits instead, but in that case the ::boost:: namespace must be explicitly specified, since it's in a macro context and can't assume that it's being used inside the boost namespace.

Most of the clang-specific macro definitions in this area appear to have the same problem, although oddly these particular ones appear to do it both ways for some reason.

[uecasm]

Although while the above is definitely a bug in its own right, possibly of note is that the location that actually flagged the error to me was this:

type_traits/include/boost/type_traits/has_trivial_move_assign.hpp

Line 49 in efc0be6

BOOST_HAS_TRIVIAL_MOVE_ASSIGN(T)

Which does happen to be in the boost namespace. Which suggests that there's an additional problem of a missing #include dependency. Though it looks like ad32684 fixed that particular issue.

[jzmaddock]

This should have been fixed in ad32684#diff-6f32db8e7667635f00953149c5f40853.

Can you please update to 1.70 and report back?

[uecasm]

Did you see my last comment? I acknowledged that.

The macros still have public names (even if perhaps they are not intended for public use -- in which case perhaps they should be renamed), and in their current form they are implemented inconsistently and won't work if used outside of the boost namespace.

[jzmaddock]

The macros are not intended for use anywhere except inside the type traits library.

Yes, they are documented: but that's so that folks can implement them for compilers about which we currently know nothing. Which is to say they are a customisation point for type_traits, but NOT user usable.

If you wish to submit a PR to fix the perceived issue that's fine, but unless you have a use case where Boost-1.70 fails, I see no need to chase after this myself.