On Jun 14, 2007, at 12:09 PM, Eric Niebler wrote:
Maurizio Vitale wrote:
This one took me a long time to understand, and now that I think I understand it, I'm pretty sure I don't like
Apparently (at least in the situation shown below, with user defined domain and expressions) unary_expr matches terminal< >. This was surprising to me because I was working under the assumption that unary_expr matched only bona-fide unary C++ operators.
Your understanding of the issue is correct. The implementation is dead simple, and the behavior you're seeing naturally falls out of the decision to make terminals behave like degenerate unary expressions. They are unary expressions because they store one datum inside, just like a "real" unary expression does.
I agree that letting terminals match unary_expr<_,_> is a little surprising, though. I can easily patch up proto::matches<> such that tag::terminal does not match _, so that a terminal will not match unary_expr<_,_>. It *will* still match unary_expr<tag::terminal,_> though. Would that be ok?
Would be helpful (and would solve my specific case completely), but if you could find a way to completely hide the fact that a terminal is a unary_expr from the user I think it would be much cleaner for a boost::proto release. Regards, Maurizio