From: Gordon Woodhull
My yes vote is still conditional on your cooperation with us on letting floating points work, because the library would not be useful to me otherwise.
Technically, there's nothing in the code that would disallow the use of floats, only that there is the warning in the docs. I have already stated (though maybe not clearly enough, so I will try again now ;-), that I will explain possible issues with floats and make the warning sound less categorical. Is this what you expect?
I am now regretting that I didn't look at the code, because I didn't know that there were assertions testing the invariants in a different way from the predicates.
The assertions test the invariant exactly the same way, they use the predicate.
Is this only in the bounded part of the library?
No, the constrained class contains those assertions.
I thought the value was tested after every change using the predicate, and then called the error policy if the predicate failed.
Value should be changed _after_ calling the predicate to ensure strong excepiton guarantee.
Generally I don't think a library should assert on any user input - even an invalid/inconsistent predicate!
If the user of a library breaks the contract, then why not? I'd rather prefer to see a failed assertion to know as soon as possible that I accidentally used the library in an inproper way.
I figured this was the point of having an error policy - everyone has their own idea how they want to handle errors.
Error policy and the assert are two different things. Error policy guarantees the invariant, the assertion verifies it (and thus verifies the contract). Assigning an invalid value is a different kind of error than breaking the contract.
Assertions are forbidden in a lot of corporate environments.
Isn't it what BOOST_DISABLE_ASSERTS is for if you want to prevent a Boost library from using asserts?
I guess we have to wait for decltype to be able to use lambda expressions as predicates here?
Why? There are already examples with lambda predicates in the docs. Best regards, Robert