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 13:57:12
> 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.
Ohh, sorry, I misunderstood. That's a good question indeed. However, I have
no answer, yet.
> 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
> > 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
Proto list run by eric at boostpro.com