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-23 13:13:14

On 23.04.2013, at 08:48, Andrew Ho <helloworld922_at_[hidden]> wrote:

> However, the main concern is that in practical code it may be difficult to 
> identify and isolate issues which could crop up. The question is do we try to 
> provide safer code, more efficient code, or both?

If possible: Obviously both. I think that efficiency should be the primary goal, otherwise people will end up not using Boost.Operators in performance-critical applications and they will write their own code which might have even more bugs/problems. Safety is therefore also important, but in case of doubt I think we should use the more efficient code and document the pitfalls. I guess C++ already has a history of that approach :) If the only problem is binding a reference to the result it's also explicitly visible in the user's code, it's not something that introduces a bug silently.

> What compiler-specific code should the re-write reasonably have to take into 
> account? Only standard-compliant features, or are there some notable 
> exceptions of known issues? I'm assuming we're going to at a minimum support 
> C++03 and C++11 versions. Also, should we worry about maintaining the NRVO 
> code?

The major guidelines from my point of view are:

- If no one can and will test an existing work-around, there is no point in keeping it.
- If someone is able and willing to test, the work-arounds should not have any negative impact for conforming/good compilers.
- C++11 should be optional, using Boost.Config to detect support for rvalue references, noexcept, …
- NRVO: Do you mean the work-around in case the compiler is *not* able to apply the NRVO? Good question.

> The last thing I can think of is what about the left operators? Should they be 
> provided in a similar fashion like commutative/non commutative?

I don't quite understand what you have in mind, could you elaborate, please? For df.operators, you already have the choice of using commutative_foo<T,U> 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 possible, be very conservative 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 the complexity of discussions, 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, please give me your preferences for either 1) or 2), thanks!

Regards, Daniel