Proto for Boost mailing list page: Re: [proto] problems with proto::matches

Subject: Re: [proto] problems with proto::matches
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2013-01-07 05:33:49

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.