Re: Silly and stupid post-condition or not ?

["Randy Brukardt" <randy@rrsoftware.com>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccobtdfgz9.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> The postcondition (and precondition) moves this "contract" information to
>> where it belongs (on the specification).
>
> Right.  That's what makes a precondition better than simply putting
> a pragma Assert at the start of the procedure body.
>
>>... That allows the compiler to take
>> advantage of that information, and in many cases completely eliminate the
>> associated checks (just like the compiler can eliminate a large 
>> proportion
>> of constraint checks). Like constraint checks, well-written contracts 
>> should
>> never need to be turned off...
>
> I don't agree.  There are definitely cases when constraint checks
> should be turned off.  Likewise preconditions.  If you say
> "Never turn off checks", you're really saying "Never write
> an assertion that is too expensive in production, even
> though it might be helpful in testing and debugging",
> which is clearly counter-productive.

I would indeed argue that. More accurately, what I would argue is that any 
assertion that is too expensive to "use in production" be kept completely 
separate from the rest, and I'd suggest that it generally be turned off 
(unless absolutely needed).

I've done this in my programs by simply commenting them out; they're only 
inserted when the problem that they are intended to detect shows up a second 
time. (That doesn't happen much.) I could see using some other mechanism to 
keep them separate; possibly going so far as to using a dynamic method to 
turn them on or off.

This has always been one of my biggest complaints with Assertions; all or 
nothing is insufficient control; it's bad enough that I've never seen any 
real value to pragma Assert. (I'd rather use if statements controlled from a 
global package than to use a single compiler switch for such detection.)

>>...(as always, it's like taking off the seatbelts
>> when you leave the garage...).
>
> I don't buy this analogy (nor the similar one about life jackets and
> sailboats).  Seatbelts often save lives and reduce injuries
> when something goes wrong.  Preconditions (etc) don't cause
> programs to give correct answers when something goes wrong
> -- they just detect the wrongness.

Turning off constraint checks make a program erroneous, and thus the program 
can return wrong answers without any notice. Back in the CP/M/MS-DOS-1 days, 
we used to have this problem a lot, especially by accessing non-existent 
variants. And a lot of those problems only showed up in production.

Today, this sort of thing is a security problem - constraint checks at least 
bound the problem to at worse a denial-of-service problem, much less of a 
problem than allowing a buffer overflow that allows anything to be executed.

I admit that is less of a problem for preconditions and the like, but I 
think the same holds true -- particular if the correctness checks were 
removed from the code in favor of the preconditions.

> By the way, I find that when I (at first) think I want a
> pre/post, it's usually better expressed as a subtype predicate.
> My favorite new feature of Ada 2012.

I agree. I originally thought that predicates were a better solution to the 
problem than pre/post/invariants. I still do for most uses, but of course 
whenever multiple parameters are involved you have to use a precondition 
instead.

                                                 Randy.