> > 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 _______________________________________________ proto mailing list email@example.com http://lists.boost.org/mailman/listinfo.cgi/proto