std.locale

[Sean Kelly]

== 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.

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