assume, assert, enforce, @safe

[Dicebot via Digitalmars-d]

On Friday, 1 August 2014 at 19:10:34 UTC, Walter Bright wrote:
> On 8/1/2014 6:12 AM, Dicebot wrote:
>> 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.
>
> What makes me hesitate about use of enforce() is its high 
> runtime cost. It's not just the computation, but the call stack 
> above it is affected by enforce() being throwable and 
> allocating via the GC.

`enforce` does have overload which allows to use pre-allocated 
exception instance. Or, alternatively, we may need a similar 
helper wich does `if (!condition) abort()` with no interaction 
with -release or optimizer.

Whatever is chosen it does seem that contracts can't be used in 
application code because it is too affected by user input and is 
too likely to expose hidden bugs in production.

> Secondly, enforce() is about recoverable errors. Program bugs 
> are simply NOT recoverable errors, and I cannot recommend using 
> them for that purpose. I've argued for decades with people who 
> insist that they can write code that recovers from unknown 
> programming bugs.

1) one can always `enforce` with a pre-allocated Error, will 
druntime handle that as expected?

2) There is certain class of applications where even programming 
bugs can (and must be) considered recoverable. Network services 
that don't yet have full scale high availability infrastructure 
(and thus can't afford downtime of restarting the app) are quite 
likely to only terminate connection fibers when programming bug 
is found - it does not affect serving any other connections. It 
may be fundamentally wrong but is is pragmatical working approach.

These questions are not theoretical - we regularly have 
discussion about how contracts may / should be used at work with 
no clear understanding / agreement so far. I am interested in 
simple set of guidelines that won't turn writing every single 
function in a guessing game (does a contract fit here?)