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: eric_at_[hidden]
Date: 2010-12-24 10:16:24

(Sorry for the top-post)

Just because a type is a Fusion sequence, that doesn't mean it has boost::fusion as an associated namespace. I'm asking why boost::fusion::operator< is in the overload set. 

Eric

Sent via tiny mobile device

-----Original Message-----
From: "Hartmut Kaiser" <hartmut.kaiser_at_[hidden]>
Date: Fri, 24 Dec 2010 08:55:16 
To: 'Eric Niebler'<eric_at_[hidden]>
Cc: 'Spirit Development'<spirit-devel_at_[hidden]>; 'Christopher Schmidt'<mr.chr.schmidt_at_[hidden]>; 'proto'<proto_at_[hidden]>
Subject: RE: [Spirit-devel] [Spirit Development] Bug in today's boost_trunk --	ambiguous operator >


> > 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