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

Subject: Re: [boost] [operators] A modern SFINAE-based version of boost::operators?
From: Daniel Frey (d.frey_at_[hidden])
Date: 2017-11-13 16:26:41

> On 13. Nov 2017, at 15:20, Beman Dawes via Boost <boost_at_[hidden]> 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<Me,int,double> { ... };

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.