On Tue, Feb 13, 2018 at 1:51 PM, Steven Watanabe via Boost < boost@lists.boost.org> 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@lists.boost.org> 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
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