From: Stjepan Rajko On Tue, Dec 2, 2008 at 6:53 PM, Robert Kawulak <robert.kawulak@gmail.com> wrote:
The rule is that the result of the constraint invocation for the value must
always be identical as
long as you don't access either of them as non-const. [...] Perhaps a concise way to describe a requirement (addressing both these cases, as well as the const mutable problem) is to say that the constraint must depend only on what is mutable by expressions that require a non-const reference to the underlying object?
Not exactly. Constraint may depend on its own state too, but again it's not an allowed situation if constraint may be somehow altered by a const reference and change its judgement for unchanged value.
Are there also requirements that the way in which the underlying object is CopyConstructable and/or Swappable maintain the constraint?
Implicit, yes.
value_type temp = x.value(); f(temp); x = temp;
If this is a frequent use case, I'd prefer to be able to write call_using_copy(f, x); or call_using_copy(&f, x); or something like that.
So is it a frequent use case? I have no idea. I never needed this.
I just looked at the code (it's very nice to look at!), and am trying to get a grasp on the policy design. At first I had some doubts about it, but am getting more and more convinced that you have the design right. This is what I understand: * the policy gets called iff there is a problem * a problem happens when the underlying object is constructed with an invalid value, in which case the policy gets called with that invalid value as both the first and second parameters * a problem happens when an invalid value wants to be assigned to the underlying object, in which case the policy gets called with the current (valid) value as the first argument, and the new (invalid) value as the second argument * the first argument must satisfy the constraint when/if the policy returns.
Exactly. As to the last point -- more generally, the first argument must satisfy the third argument (which can also be modified by the policy). Regards, Robert