Re: [boost] [operators] A modern SFINAE-based version of boost::operators?

On 13. Nov 2017, at 15:20, Beman Dawes via Boost wrote:

Peter Sommerlad, committee member and C++Now presenter who often proposes additions to fill in holes in the standard library, asked me:

Are you aware of anybody who tried to provide a boost::operators style of automatically providing additional operators with a single base class that through SFINAE injects all possible operators based on the ones defined in the template parameter? This won't give you the control of the current boost::operators, but would be much easier to teach.

I'm the current maintainer of Boost.Operators and I heard about anyone working on that. A few thoughts from my side: I worked on other improvements, which ultimately went into its own library: https://github.com/taocpp/operators. There, I distinguish between commutative and non-commutative versions of some operators, as they allow me to provide additional optimisations (leading to fewer temporaries). This could not be done with a detection-style approach as the presence of an operator+ will not tell you whether or not it is commutative. It also plays some tricks returning rvalue-references which some people don't like (or consider dangerous), so it's not suitable for Boost.Operators. Leaving that aside, I'd be willing to accept an *additional* base class for Boost.Operators just like you outlined. This *might* go into its own header as the current Boost.Operators library supports some quite ancient compilers and I don't want to break people's code. It also allows users to fall back to the existing approach if necessary, for example if the SFINAE-based code is too slow to compile. Or if you simply need more control of what exactly will be generated. However, there will be a few questions: Shall we generate == if only < and > are provided? What about additional types? Think: x < 0 - shall we detect/generate them as well? Maybe something like this: struct Me : make_operators_for { ... }; would try to detect Me==Me, Me==int and Me==double. But what if there is only one Me==long? Shall we detect the exact signature or if it is callable with the given parameters? That said, I think it is not a straight-forward task and I'm not sure if it is worth it, but you or anyone else: Feel free to work on it and we'll see if it turns out fit for inclusion into Boost.Operators.