On Jun 14, 2007, at 7:00 PM, Eric Niebler wrote:
Maurizio Vitale wrote:
On Jun 14, 2007, at 12:57 PM, Eric Niebler wrote:
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. I'll give the issue some thought. One possibility is shoehorn into
Maurizio Vitale wrote: proto the concept of a nullary expression, which is what terminals should rightly be. Of course, what is there already works, so IMO there are bigger fish to fry first.
I think "usability" considerations play a big role in a library acceptance.
I'm willing to bet that you have been taking advantage of the usability that terminals-as-unary-expressions brings, without even noticing it.
Q: How do you get the argument of a unary expression? A: proto::arg().
Q: How do you get the value out of a terminal? A: proto::arg().
This works because terminals have one "argument", just as unary expressions do. I like this. I don't want to have to use a separate function to extract the argument from a terminal. But if I draw a crisp line between terminals and unary expressions, I might have to.
Maybe. I don't have the familiarity you have with the implementation. I don't immediately see why between overloading (for run-time calls) and specialization (for compile-time dispatching) it shouldn't be possible to have the same name for proto::arg() for terminals and unary_expr (with different implementations where needed). But if it comes to that, I'd personally prefer different names for ::arg than unary_function matching a terminal: the former is easy to learn and getting it wrong would result in compiler errors, the latter can result in hard to track errors.
Otherwise, the line stays blurry.
I really don't think it's as cut-and-dry as you make it. I'll think about it.