Boost C++ Libraries: Ticket #9913: boost::has_complement of enum class does not compile

attachment set

Tue, 15 Apr 2014 19:36:18 GMT

attachment → a.cpp

Reproducible test case

Wed, 16 Apr 2014 14:27:55 GMT

Discussion on Stack Overflow seems to indicate the bug is in Boost: <http://stackoverflow.com/questions/23108590/is-this-valid-c11>.

Wed, 16 Apr 2014 21:29:44 GMT

Bug filed against clang current behavior <http://llvm.org/bugs/show_bug.cgi?id=19452>.

owner changed

John Maddock — Wed, 23 Apr 2014 12:29:56 GMT

owner changed from John Maddock to bronf

Confirmed that this is a problem with our code - it seems that class enum's are unique in not accepting these operator overloads. Given that, I'm actually not sure if it's even possible to implement has*operator for class enum types :-(

Reassigning to the author of those files in the hopes of a fix....

Wed, 23 Apr 2014 15:51:28 GMT

Here is my C++11 only version of has_complement:

    namespace detail
    {
        namespace has_complement_impl
        {
            struct dont_care {};
            template<typename Rhs, typename Ret>
            class has_complement_trait
            {
                template<typename Hs,
                         typename Et = decltype(~std::declval<Hs>()),
                         typename = typename std::enable_if<std::is_same<dont_care, Ret>::value ||
                                                            std::is_convertible<Et, Ret>::value>::type>
                static true_type has_complement_operator(int);
                template<typename>
                static false_type has_complement_operator(...);
            public:
                using type = decltype(has_complement_operator<Rhs>(0));
            };
        }; // has_complement_impl namespace
    } // detail namespace
    template<typename Rhs, typename Ret = detail::has_complement_impl::dont_care>
    struct has_complement
    : detail::has_complement_impl::has_complement_trait<Rhs, Ret>::type
    {};

John Maddock — Wed, 23 Apr 2014 17:06:51 GMT

Thanks that's really neat!

Hopefully Frederic Bron will take this up as he's much more familiar with the internals of these traits than I am.

Note that the issue effects not just the unary operators, but all the binary operators such as has_plus etc suffer the same issue.

We also need to figure out what config macros will determine when the above approach can be used - BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS and BOOST_NO_CXX11_DECLTYPE certainly, possibly BOOST_NO_SFINAE_EXPR as well.

status changed; resolution set

John Maddock — Thu, 02 Aug 2018 11:31:12 GMT

status new → closed
resolution → obsolete

Moved to https://github.com/boostorg/type_traits/issues/80