Re: [boost] [operators] The future of Boost.Operators

Subject: Re: [boost] [operators] The future of Boost.Operators
From: Daniel Frey (d.frey_at_[hidden])
Date: 2013-04-25 16:50:18

On 25.04.2013, at 13:19, Daryle Walker <darylew_at_[hidden]> wrote:

>> 3) Support for constexpr if this is applicable at all. I haven't found the time to properly research it yet.
> 
> I've discussed this somewhere, but this library and constexpr are incompatible.  The dependency between operator?? and operator??= is backwards to what constexpr needs.
> [...]
> You can compose the regular version of an operator in a constexpr way if you have the right initialization.  But the compound-assignment operators are inherently mutating, so they can never be constexpr.  Defining the regular versions in terms of the compound-assignment ones bars them from being constexpr.  You can reverse the dependencies to save code.

Thanks Daryle, that really helped me to get a clearer picture on the topic. I think I only have two questions left:

1) How could "reverse the dependencies" save code? Could you elaborate, please?

2) Given a set of non-constexpr overloads, could the user add even more overloads for constexpr and what is required for this to work? Example:

struct X : private df::commutative_addable< X >
{
  X& operator+=( const X& );
};

constexpr X operator+( constexpr X lhs, constexpr X rhs ) {…}

is the above possible? Are there problems/conflicts? What are the requirements for the non-constexpr overloads and the signature/requirements for the user-defined constexpr-overload to play together nicely?

Best regards, Daniel