Re: [Spirit Development] Bug in today's boost_trunk -- ambiguous operator >

> >> Seems we're back to square one, where Fusion and Proto need to be
> >> changed to avoid this kind of ambiguities. I still believe that's the
> >> right thing to do, as the issues are caused by (potential)
> >> ambiguities introduced by making proto expressions to be fusion
> sequences in the first place.
> >
> > This has recently been a recurring problem. I'm highly considering
> > putting all of fusion's components in ADL barriers.
> 
> I agree. This breaks a lot of code but in the long term we will avoid lots
> of trouble.
> Unfortunately 1.46 is closed for major changes on the 10th of January.
> That does not leave much time for implementing, testing and documenting
> such a change. Fusion itself internally relies on ADL - we'd need to audit
> every line of Fusion in order to get it working again.
> 
> Is a preliminary revert an option? If we reverted [67342] and [67352], it
> would work again?

I don't think this is necessary. The changes suggested (moving at least the
two fusion traits detail::enable_equality and detail::enable_comparison)
into a public place (i.e. fusion::traits) and adding SFINAE enabling
template parameters should do the trick for now:

namespace boost { namespace fusion { namespace traits
{
    template <typename Seq1, typename Seq2, typename Enable = void>
    struct enable_equality
        : mpl::or_<traits::is_sequence<Seq1>, traits::is_sequence<Seq2> >
    {};

    template <typename Seq1, typename Seq2, typename Enable = void>
    struct enable_comparison
        : mpl::and_<
            mpl::or_<traits::is_sequence<Seq1>, traits::is_sequence<Seq2> >
          , mpl::equal_to<result_of::size<Seq1>, result_of::size<Seq2> >
        >
    {};
}}}

Regards Hartmut
---------------
http://boost-spirit.com




------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl