QuoteOriginally posted by: CuchulainnQuoteThis is a type of C++ policy version that Polter mentioned, .. the user can pick which version he wants -there is no truth-... you can forward the validator reference to sub-calls.That is a way. But you have modified the signature of my function. So a solution to a slightly different problem.. The specifications have been changed.Specifically, BS returns a double and your code returns essentially two values. Don't CS call that side-effects? What happens if the user 1) no validation policy checks and 2) calls BS(y) with y < 0? Crash, _yes_? (1)I think you are saying "Customers is always right" and that is not always (never!) so.But I think the validators are the preconditions that should be defined by the supplier. Supplier cannot take risks. Conclusion: code is not clear on the contract, it has errors leading to defects and faults based on assumption/case (1) above. If your code example is representative you are saying that clients may choose policies? _yes_?Maybe I misunderstand the intent of the example.Perhaps the signature of your code SHOULD be changed. One general policy would be that any code that accepts a double MUST gracefully accept all possible values of double. If the code presumes pre-validated inputs (i.e., a subset of doubles), then the signature would reflect that.The other issue is whether "safety" should be handled at run-time or compile-time. Perhaps some versions of the code should be idiot-proof with all the requisite validation built in albeit with some runtime performance penalty. But other bare-bones versions of the code are for "professionals only" and assume that that the caller has prevalidated any inputs either by prechecking the input or by proving that the calling code can never generate an out-of-range value.Does one give a Husqvarna to a child?