On 25.04.2013, at 13:19, Daryle Walker
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