assume, assert, enforce, @safe

[Dicebot via Digitalmars-d]

On Thursday, 31 July 2014 at 21:11:17 UTC, Walter Bright wrote:
> On 7/31/2014 1:52 PM, Sean Kelly wrote:
>> Could you expand on what you consider input?
>
> All state processed by the program that comes from outside the 
> program. That would include:
>
> 1. user input
> 2. the file system
> 3. uninitialized memory
> 4. interprocess shared memory
> 5. anything received from system APIs, device drivers, and DLLs 
> that are not part of the program
> 6. resource availability and exhaustion
>
>
>> For example, if a
>> function has an "in" contract that validates input parameters, 
>> is
>> the determination that a parameter is invalid a program bug or
>> simply invalid input?
>
> An "in" contract failure is a program bug. Contracts are 
> ASSERTIONS ABOUT THE CORRECTNESS OF THE PROGRAM LOGIC. They are 
> not assertions about the program's input.
>
>> If you consider this invalid input that
>> should be checked by enforce(), can you explain why?
>
> This says it better than I can:
>
> http://en.wikipedia.org/wiki/Design_by_contract

ok, can this be considered a good summary of using 
assertions/contracts for services where risk of entering 
undefined state is unacceptable?

1) never use `assert` or contracts in actual application code, 
use `enforce` instead
2) never use `enforce` in library code unless it does actual I/O, 
use contracts instead
3) always distribute both release and debug builds of libraries 
and always run tests in both debug and release mode

Does it make sense? Your actual recommendation contradict each 
other but it is best what I was able to combine them into.