checkedint call removal

[Walter Bright via Digitalmars-d]

On 7/29/2014 3:13 AM, Dicebot wrote:
> On Tuesday, 29 July 2014 at 07:31:26 UTC, Walter Bright wrote:
>> You can choose to disable assertions with a switch, or not. Having a choice up
>> to you doesn't make it useless.
>
> Yes I know what are options to make it work. I don't know how to make it work
> "in a good style". This is not just D problem - I feel like something is missing
> in the design by contract idea, something that actually can make it robust
> enough to be used without "oh crap" moments.

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 can see this 
in dmd which often exhibits a fault as a tripped assert. But if for nothing 
else, a way to turn them off gives the developer an easy way to see exactly how 
much they cost him in performance, so he can make the best decision for his 
application.

I've also been known to use debug versioning to add a bunch of extra testing 
code for dev testing.


>> Also, assertions are not for validating user input.
> This is one of problems. When writing library function you don't exactly know if
> input is going to be user input. Use enforces - and it won't be possible to
> optimize away redundant checks. Use assertions and issue may slip uncaught.

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.

Asserts are meant to test for logic bugs in the program. Nothing else.


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