
I don't quite understand what you have in mind, could you elaborate,
have the choice of using commutative_foo
which provides both T foo U and U foo T (as it is commutative) and for the non-commutative version, you still have foo< T, U > for T foo U and foo_left< T, U > for U foo T. In general, I see two major options to improve Boost.Operators:
1) Small steps to improve the existing implementation, be as compatible as
about changes. That might also mean to end up with a compromise and not with the best API and implementation for the conforming and good compilers and the people using them.
2) Leave Boost.Operators as it is and develop Boost.Operators v2 (using df.operators as a base?). This should allow for breaking the API for the better and to have a much cleaner implementation. Old compilers that need strange work-arounds can still use Boost.Operators v1 and they are unlikely to benefit from rvalue-reference support anyways.
I think that 2) might be the better option, giving us more freedom, reduce
decisions and the implementation while not breaking any existing code: Users need to explicitly decide to switch to v2, otherwise all existing code remains untouched. Everyone,
Daniel Frey
preferences for either 1) or 2), thanks!
Ahh, true. left is only relevant for non-commutative.
What about using partial template specialization for handling
commutative/non-commutative versions? This should make implementing 1) much
easier, and I think is a slightly more elegant/flexible solution.
Here's some sample code:
// non-commutative
template