On Thu, Jul 31, 2014 at 02:05:29AM +0000, Tofu Ninja via Digitalmars-d wrote: > On Wednesday, 30 July 2014 at 22:01:23 UTC, Walter Bright wrote: > > >3. Use of assert to validate input is utterly wrong and will not be > >supported. Use such constructs at your own risk. > > When exactly is it 'ok' to use assert then? > > If asserts are not allowed to be used to verify inputs.... then by > extension, they can not be used to verify any derivative of an input.
No that doesn't make sense. The idea behind input sanitization is that user-facing APIs receive arbitrary, unverified input from outside, and before you use that data, you scrub it. After scrubbing it, it's perfectly OK to use assert to verify its validity -- because if it's still invalid, there's a bug in your scrubbing algorithm. The scrubbed input *is* a derivative of the input, but you can't say that you can't use assert on it! (And if you *don't* scrub your data before using it, your design is flawed and should be fixed.) > So by that definition, asserts are only ok to use on any thing known > at compile time... that makes them utterly useless.... Your definition is wrong. ;-) The idea behind asserts is that you're verifying *program logic*, not checking arbitrary input data. If you have an algorithm that computes a square root, for example, you'd use an assert to verify that the square of the result equals the input -- because if not, that means something has gone wrong with your square root algorithm. But you shouldn't use an assert to verify that the input to the square root algorithm is a valid numerical string -- because the user could have typed "abc" instead of a number. Rather, you should scrub the user input and throw an exception when the input is invalid. After scrubbing, however, it's perfectly valid to assert that the input must be a valid number -- because if not, it means the *logic* in your scrubbing algorithm is flawed (perhaps it missed a corner case). It's true, however, that this simple idea is not always so simple in practice. One has to draw a line between "user input" and "internal state" somewhere, and it's not always obvious where that line falls. For example, viewed as a whole, the entire software application may be considered a system that takes input from outside, so "user input" means things like keystrokes, mouse movements, etc.. But internally, the system may consist of multiple components, and when data is passed between components, should they be treated as "internal state" or "user input"? Should library APIs treat application input as "external input" and vet it before use, or is it OK to use assert to enforce(!) the validity of data passed internally between the application's components? It's not always easy to decide, and sometimes judgment calls have to be made. T -- If creativity is stifled by rigid discipline, then it is not true creativity.
