On Tuesday, 29 July 2014 at 19:35:31 UTC, Walter Bright wrote:
To have an assert despite -release, you can do things like:
assert(exp); => if (!exp) assert(0);
I generally leave asserts in for released code in my projects.
You honestly don't smell a problem here? There is a default
behavior dmd uses and you (compiler author!) disable it because
non-default one seems more practical. If this does not indicate
something is wrong with the system I don't now what does.
You can see this in dmd which often exhibits a fault as a
tripped assert.
Exactly. And same is for our Sociomantic projects - those never
get compiled with -release because programs have bugs and you
want to be able to detect bugs instead of corrupting the service.
asserts indicate bug in program logic but removing them in
release builds means letting those bugs lose. In practice I can't
imagine a situation where one can afford such risk, not even with
100% test coverage (because code paths that trigger assertions
are not covered in a working program)
It's a serious, serious mistake to use asserts for user input
validation. If passing raw user input to a library function,
unless that function is specifically documented to validate it,
you've made a big mistake.
I know it all well and it doesn't help in practice even tiny bit.
It is not something as naive as just calling the function with
user input. All such cases are programming bugs that do not get
caught by tests but trigger upon user input code paths. Bugs that
will get unnoticed if default -release is used.
It feels like for contracts to really work some good
implementation of red-green
code zones is necessarily, to be able to distinguish user
input call paths from
internal ones during compilation time.
That's not what contracts are for (beating a dead horse).
Joel Spolsky made a suggestion I like - have raw user input be
of a different type than validated input. That way, functions
are clearly and checkably red-green zoned.
Ironically it is the very same thing I have suggested in quoted
part but you call it wrong :) Thew way it interacts with
contracts is that it becomes possible to define validated program
sub-system known at compile-time which has much better chance to
be tested good enough to afford omitting assertions and contracts.
