Hi,
Just so you know, it's my feeling that the 'range constraint' is the most frequent and most of the more complicated cases you can imagine don't come up that much in practice. I'm not even sure it's really worth supporting.
It seems to be the most frequent and most important, but I think we shouldn't close the door for the other not-so-common-yet-occuring-from-time-to-time constraints, because it's easy to let them work. One day you may need to have a type for odd numbers only, for lowercase strings only or for strings containing numbers only, and the template will be ready here :)
The most important thing is to allow customization of the error handling and set it up so the details of the constraint violation can (eg: min or max) can be determined. Again I've been skimming so I don't know if your code does this or not.
Customisation of the error handling - yes, reporting details of constraints violation - not implemented, but very easily supported.
That's not good. I guess you'd need need one of the policies to specify the default value if it is allowed. In the date-time constrained_value there is no default constructor as I recall.
Right, in my implementation if you want to use default construction, the policy must supply initialize() member for this purpose. Best regards, Robert