Named operators in C++ A post by Yakk alerted me to  the idea of named operators in C++. This look splendid (albeit very unorthodox). For instance, the following code can be made to compile trivially:

vector&lt;int&gt; vec{ 1, 2, 3 };

cout &lt;&lt; "3 in " &lt;&lt; vec &lt;&lt; ": " &lt;&lt; (3 &lt;in&gt; vec) &lt;&lt; '\n'
     &lt;&lt; "5 in " &lt;&lt; vec &lt;&lt; ": " &lt;&lt; (5 &lt;in&gt; vec) &lt;&lt; '\n';


Of course the whole thing has to be generic so any binary function-like thing can be used to define operators, e.g.

auto in = make_named_operator(
    [](int i, vector&lt;int&gt; const&amp; x) {
        return find(begin(x), end(x), i) != end(x);
    });


I’d like to know whether the following implementation is sufficient to handle all “interesting”1 cases, and whether it’s robust. For instance, I’m storing the operands in references. That should work since they’re only stored until after the expression has completed, and thus should never go stale. I’m especially interested in feedback on the return types of the operator functions below and on the design rationale of using the &lt;…&gt; syntax for named operators.2

It seems to handle templates as well as a mixture of different types (and cv-qualification).

#include &lt;utility&gt;

template &lt;typename F&gt;
struct named_operator_wrapper {
    F f;
};

template &lt;typename T, typename F&gt;
struct named_operator_lhs {
    F f;
    T&amp; value;
};

template &lt;typename T, typename F&gt;
inline named_operator_lhs&lt;T, F&gt; operator &lt;(T&amp; lhs, named_operator_wrapper&lt;F&gt; rhs) {
    return {rhs.f, lhs};
}

template &lt;typename T, typename F&gt;
inline named_operator_lhs&lt;T const, F&gt; operator &lt;(T const&amp; lhs, named_operator_wrapper&lt;F&gt; rhs) {
    return {rhs.f, lhs};
}

template &lt;typename T1, typename T2, typename F&gt;
inline auto operator &gt;(named_operator_lhs&lt;T1, F&gt; const&amp; lhs, T2 const&amp; rhs)
    -&gt; decltype(lhs.f(std::declval&lt;T1&gt;(), std::declval&lt;T2&gt;()))
{
    return lhs.f(lhs.value, rhs);
}

template &lt;typename T1, typename T2, typename F&gt;
inline auto operator &gt;=(named_operator_lhs&lt;T1, F&gt; const&amp; lhs, T2 const&amp; rhs)
    -&gt; decltype(lhs.value = lhs.f(std::declval&lt;T1&gt;(), std::declval&lt;T2&gt;()))
{
    return lhs.value = lhs.f(lhs.value, rhs);
}

template &lt;typename F&gt;
inline constexpr named_operator_wrapper&lt;F&gt; make_named_operator(F f) {
    return {f};
}


For the interested, a full example implementation is on GitHub.



1 &lt;insert your definition of “interesting” here&gt;

2 I considered other alternatives, such as %…% which is used by R, and allowing different operators (as done by Yakk) to allow for different operator precedences but I decided against that because I think it makes operator precedence even more complicated than it already is in C++.
I would add rvalue reference support with moving of temporaries.

&lt;op&gt; seems to be too low precidence to be practical - you end up having to (bracket) everything (as demonstrated above).  % at least binds tightly.

I do like a &lt;op&gt;= b.  Better than my a +op= b.

Forwarding operator() from the operator to the function lets you forget the function behind the operator entirely:  in(3, vec) -- very Haskell.

N ary infix operators that defer application of f allow s &lt;append&gt; s2 &lt;append&gt; s3 to run as efficiently as possible.  But doing that cleanly might be hard.

Not sure what inline is intended to do above.

For an interesting test case, implement (std::future&lt;T&gt; %then% [](T)-&gt;U)-&gt;std::future&lt;U&gt; (where that lambda is a placeholder for a functor)

Block some copy and move ctors to prevent persistance, and friend the approriate operators.

As noted, I allowed arbitrary binary operators (chosen when you make_infix) to bracket the named operator: the precidence of the resulting named operator exactly matches the bracketing operators.  So +append+ has precidence of + and *in* has precidence of *.  Of the 3 first use cases (lin alg, container append, then) for two of them the named operators where variants of existing operators, and matching their precidence seemed useful.