Proto for Boost mailing list page: Re: [proto] [Spirit-devel] [Spirit Development] Bug in today's boost_trunk -- ambiguous operator >

Subject: Re: [proto] [Spirit-devel] [Spirit Development] Bug in today's boost_trunk -- ambiguous operator >
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2010-12-24 09:55:16

> > I'm currently running the Fusion tests to see whether the additional
> > 'typename Enable = void' break anything. But I expect everything to
> > work - Yep everything is fine.
> >
> > Eric, would you be willing to add the specializations above to Proto's
> > Fusion adaptation code?
> 
> Doable, but I would feel better if these were documented customization
> points of Fusion. At least move them out of the detail namespace.

Agreed, and I believe, doable.

> Note that if we had Concepts, the Fusion operators would be restricted to
> models of IsComparable, which presumably would require that each element
> of the sequence could be compared and that the result was convertible to
> bool. By that definition, a Proto expression is *not* a model of
> IsComparable. What you're asking me (and everyone else) to do is to
> explicitly state that my type does *not* model the concept. It might be
> expedient in this case, but it feel vaguely wrong to me.

I'm agreeing on all points.

> I'm still curious why an operator in the Fusion namespace is even being
> considered. How did boost::fusion become an associated namespace of
> spirit::qi::rule?

The qi::rule is a proto expression and as such a fusion sequence. The
default fusion::detail::enable_comparison checks whether the operands are
(const) fusion sequences, which makes rule a, b, c = a > b; a valid
operation on Fusion sequences.

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