On Wed, 03 Apr 2013 01:59:32 -0400, Lars T. Kyllingstad
<pub...@kyllingen.net> wrote:
On Wednesday, 3 April 2013 at 05:42:13 UTC, Lars T. Kyllingstad wrote:
The problem with assert is that it gets disabled in release mode.
I think it is a bad idea to have this be the "standard" behaviour of
parameter validation.
Allow me to clarify my position on assert() a bit. As a general rule, I
think assert() should be used to verify internal program flow and
program invariants, and nothing more. Specifically, public APIs should
*not* change depending on whether asserts are compiled in or not.
Say I am writing a function that you are using. I don't trust you to
always give me correct parameters, so I check them. (Maybe my function
could even do something dangerous if I didn't.)
public void myFunction(someArgs)
{
if (someArgs are invalid)
throw new InvalidArgumentError;
...
}
I disagree here. There are two "users" involved, one is the actual user,
typing a command on the command line, and then the developer who uses the
function. The developer should be checked with assert, the user should be
checked with code like you wrote.
The problem becomes apparent when developers don't check user input before
passing to your functions. That is on them, not you. The library should
be able to have all the safety checks removed to improve performance.
I wish there was a way to say "this data is unchecked" or "this data is
checked and certified to be correct" when you call a function. That way
you could run the in contracts on user-specified data, even with asserts
turned off, and avoid the checks in release code when the data has already
proven valid.
-Steve
