checkedint call removal

[Dicebot via Digitalmars-d]

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.