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

> On 12/27/2010 10:24 PM, Hartmut Kaiser wrote:
> >>>> 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:
> 
> <snip>
> 
> I see this has still not be done. Are we planning on letting this bug ship
> in 1.46?

I very much would like to have it in as soon as possible (cc'ing Christopher
again).

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




------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl