std.locale

[Georg Wrede]

Sean Kelly wrote:
> == Quote from Walter Bright (newshound1 at digitalmars.com)'s article
>> Andrei Alexandrescu wrote:
>>> I agree. I'm having the same problem: I put a contract in there, I know
>>> it's as good as assert. So I can't do e.g. input validation because in
>>> most functions input must always be validated. I also know that
>>> contracts are doing the wrong thing with inheritance and can't apply to
>>> interfaces, which is exactly the (only?) place they'd be interesting. So
>>> I send the contracts home and use assert, enforce, and unittest.
>> Contracts are not for input validation! They are checking if the logic
>> of your program is correct or not. Think of it this way - your program
>> should behave exactly the same with or without the contracts turned on.
>> Contracts should NOT be used for scrubbing user input, checking for
>> errors from other components, or validating any input from external to
>> the dll.
> 
> Why should contracts be limited to parameter checking of internally used
> functions only?  If I write a function and document parameter constraints
> then I certainly expect those constraints to be followed regardless of
> whether I'm calling the function or someone else is calling the function.
> Checking these via a contract simply provides an optional means of
> ensuring that a logic error didn't occur within the program as a whole.

The distinction is not whether you or others write stuff. It's about 
whether it is for debugging *only*, as opposed to general input validation.

Sort of, like it's not prudent to put an assert anywhere other than 
where the source code (that is, a bug or goof by the programmer) causes 
the assert to fire.

> If you're talking about application input however, then I agree completely.
> ie. stuff typed in by the user, read from a file, etc, should never be validated
> within a contract because an input failure at that level doesn't represent
> a program logic error but rather user error.  An assertion failure isn't
> a terribly good way of notifying the user that they shouldn't have put an
> alphabetic character in a box intended to receive an integer :-)
> 
> 
> Sean