Re: [boost] [constrained_value] Constrained Value review results

Subject: Re: [boost] [constrained_value] Constrained Value review results
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2010-09-12 01:38:16

On Sep 11, 2010, at 8:57 PM, Dave Abrahams wrote:
> Many thanks for taking this on and for the thorough report.  However,
> a critical piece of information seems to be missing (or buried so I
> can't find it): is the library accepted?  Conditionally or
> unconditionally?

Sorry I didn't make this clear!

Yes, the votes were unanimous in favor.  

There were conditions on acceptance from some reviewers.  In particular, 3-4 reviewers made floating point support a condition on acceptance - for many of us that is exactly what we'd want to use the library for most.  I think after debate everyone accepted that the solution didn't need to come from this library, but that Robert would have to make changes for floating point support, if needed, and to change the documentation to make it less inflammatory.

The lack of tests was the second biggest objection - the library probably should not have been reviewed without them.  Of course Robert has promised over and over to include them before the library is released.

Vicente Botet's acceptance was perhaps the most conditional, and unique, so I'll quote him:
> I would like to say that it should be accepted IF some of the following  suggestions are taken in account, as
>     * separation between constrained and constraint_adaptor
>     * use of classes instead of typedefs and removal of the free functions
>     * specialization of the operators with a possible parameter with_arithmetic_operators.
>     * adding a default value template parameter to the value type.
>     * reduction of the number of parameters of the class bounded (posible use of open<> and close<>)
>     * reduction of the number of parameters of the class bounded_int (posible use of open_c<> and close_c<>)

Thorsten Ottosen's conditions on acceptance were also numerous, but I believe they were all resolved in debate.  Thorsten, please correct me if I am wrong.

All of the items in section 3 must be addressed at least in documentation.  In some cases, they can only be addressed that way ("Substitutability with the underlying type", "Constraints not copied when operators used").

To my memory, no one asked for a second review, so it is my judgment that once Robert has addressed section 3 the library can be released.  Robert, please post any objections.

Cheers, and congratulations,
Gordon