From: Thorsten Ottosen
Yes, it is possible to check the constraint without this. The point is what happens if the constraint is not valid.
? Well, I would expect nothing to happen.
I would expect the error policy to be invoked. If the user decides (by selecting appropriate policy) that an exception should be thrown whenever his operation would cause the value to become invalid, then this should also apply to constraint modification. I would be very surprised if the operation would be simply ignored.
Error policy may need to modify the constraint, so it has to be copied (the argument of change_constraint cannot be modified).
Well, yes, but that justify to copy *also* the value and the error handler?
I suspect yes for the value (to ensure strong exception guarantee), but not necessarily for the error handler.
I also wondering if it is a good idea to let the error_policy change the constraint? Why is that useful?
We need to pass the constraint to the error policy anyway (see below). Letting it modify the constraint is safe and does not cost anything, while this allows for some more sophisticated logic of error handling (bounded object with memory from the docs being an extreme example).
And will it not mean we might pay extra for all the calls to the policy where we do not need to change the constraint in the policy?
In some cases the error policy needs to access the constraint even if it does not need to modify it. For example, the wrap policy needs to query the bounds to perform the modulo arithmetic operations. Best regards, Robert