Re: [boost] [yap] Review

Subject: Re: [boost] [yap] Review
From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2018-02-13 19:14:20

On Tue, Feb 13, 2018 at 1:51 PM, Steven Watanabe via Boost <
boost_at_[hidden]> wrote:

> AMDG
>
> On 02/13/2018 09:47 AM, Zach Laine via Boost wrote:
> > On Tue, Feb 13, 2018 at 11:30 AM, Steven Watanabe via Boost <
> > boost_at_[hidden]> wrote:
> >
> >> On 02/12/2018 06:57 PM, Zach Laine via Boost wrote:
> >>> On Mon, Feb 12, 2018 at 4:15 PM, P F via Boost <boost_at_[hidden]>
> >>> wrote:
> >>>
> >>>> You could also get rid of the need for `::user_expr`
> >>>
> >>>
> >>> We actually want that.  It's often necessary to be able to return an
> >>> expression created from some template different than the template
> >> defining
> >>> he operator.
> >>>
> >>
> >>   If that's really important then why doesn't
> >> BOOST_YAP_USER_FREE_BINARY_OPERATOR take two
> >> expr_template parameters?
> >
> >
> > Because there's only one result.   The expr_template parameter governs
> how
> > the result is constructed, not which inputs are accepted.
> >
>
>   Doesn't this make BOOST_YAP_USER_FREE_BINARY_OPERATOR
> unusable, since expression already uses it, so using it
> again with a different ExpressionTemplate would be ambiguous?
>
>
Sure, if you use both of them.  I expect people only to use expression for
quick-and-dirty small-scale uses of Yap, or for experimentation though.

However, the same problem exists if I have ET1 and ET2 that want to use
BOOST_YAP_USER_FREE_BINARY_OPERATOR.  In that case, the same ambiguity
exists.  The solution is the same as any operator overload ambiguity, I
think: sfinae.  If there's not already an appropriate constraining macro to
replace BOOST_YAP_USER_FREE_BINARY_OPERATOR (I'd have to look around a
bit), I should add one. *TODO*

Zach