On 12/13/2012 06:44 PM, Eric Niebler wrote:
On 12/13/2012 4:51 AM, Thomas Heller wrote:
Hi,
I recently discovered a behavior which i find quite odd:
proto::matches<Expression, Grammar>::type fails when Expression is not a
proto expression. I would have expected that it just returns false in
this case. What am I missing. Patch is attached for what i think would
be a better behavior of that meta function.
Hi Thomas,
Thanks for the patch. Pros and cons to this. Pro: it works in more
situations, including yours. (Could you tell me a bit about your
situation?) Also, the implementation is dead simple and free of extra
TMP overhead.
Let me try to explain what I am up to ... I am trying to implement a DSL
which has named parameter support (I adapted the toy example we did 3
years ago at https://github.com/sithhell/boosties/tree/master/options).
Consider this example proto expression:
a = foo[b = 1], c = bar[d = a]
where a,b,c and d are the named parameters. and foo and bar some
operations (doesn't matter at this point what exactly those do).
Now, since bar needs to access the parameter defined as the return value
of foo, i need to somehow concatenate the parameters. This works fine.
However, at the very beginning of the concatenation i try to concat a
"struct unused {};" with the "a" parameter expression. unused plays the
role of an empty parameter list.
In order to detect if i need to concatenate or just return the parameter
expression, i tried to use proto::matches... which lead me to the patch.
Hope that makes sense.
Cons: Someone might expect a non-Proto type to be treated as a terminal
of that type and be surprised at getting a false where s/he expected
true (a fair assumption since Proto treats non-expressions as terminals
elsewhere; e.g., in its operator overloads). It slightly complicates the
specification of matches. It is potentially breaking in that it changes
the template arity of proto::matches. (Consider what happens if someone
is doing mpl::quote2<proto::matches>.)
Ok. I admit i haven't thought about these details. Good points.
I'm inclined to say this is not a bug and that it's a prerequisite of
matches that Expression is a proto expression. If you want to use it
with types that aren't expressions, you can already do that:
template<class MaybeExpr, class Grammar>
struct maybe_matches
: mpl::if_< proto::is_expr<MaybeExpr>
, proto::matches<MaybeExpr, Grammar>
, mpl::false_
>::type
{};
Would the above work for you? I realize that's more expensive than what
you're doing now. :-(
Sorry for the lat reply ... Your proposed solution works equally fine,
of course. I'll go with that one.
_______________________________________________
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
