Thread overview
in contracts and param testing
Apr 16, 2005
Ben Hinkle
Apr 16, 2005
Kris
Apr 17, 2005
Ben Hinkle
April 16, 2005
Some of my change in dmd-120 to std.stream got me thinking about 'in' contracts and parameter checking. The stream change moved some assert statements in some 'in' contracts (eg assert(seekable)) to run-time checks in the function body that threw a StreamException if they failed. That seemed like a reasonable thing to do since the performance hit shouldn't be noticable and it's easy for users to try to read/write/seek on something that isn't readable/writable/seekable. That's why a bunch of people are now seeing various seekable failures in std.stream (those seek failures have uncovered several bugs in std.stream). They checks had always been there but since phobos is built in release mode the 'in' contracts and the asserts were turned off. One way that the problem could ahve been caught sooner is to have a non-release build on phobos. That would have helped. But it also got me thinking more about the purpose of 'in' contracts and the other contracts and asserts. It would be nice to have all parameter-checking in the 'in' contract and to _always_ compile in the 'in' contracts (well, ok, maybe give some special compiler option to not do any parameter checking). That way you always get parameter checking no matter if you turned off 'out' contracts (which check the logic of the function body) and invariants (which check the internal logic of the system). Plus the parameter checking shouldn't assert but should throw a (currently non-existant) ParamException. That way the parameter checking still happens even when the code is compiled without asserts. The invariants and 'out' contracts should use asserts.

Thoughts?
-Ben

ps - is there an easer way to say 'in' contract and 'out' contract? It looked wierd when I typed 'in' and 'out' without the quotes. Maybe I should use pre-condition and post-condition.


April 16, 2005
From what I recall, there was at least one long thread on this very topic. The last time around, there seemed to be a general call for much more control over what the compiler generates/filters in terms of invariants, pre- & post-conditions, array bounds checking, etc. I got the impression the control would be handled via a set of compiler flags.

Did those requests fall on stony ground?

- Kris



"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d3rv50$c2l$1@digitaldaemon.com...
> Some of my change in dmd-120 to std.stream got me thinking about 'in' contracts and parameter checking. The stream change moved some assert statements in some 'in' contracts (eg assert(seekable)) to run-time checks in the function body that threw a StreamException if they failed. That seemed like a reasonable thing to do since the performance hit shouldn't
be
> noticable and it's easy for users to try to read/write/seek on something that isn't readable/writable/seekable. That's why a bunch of people are
now
> seeing various seekable failures in std.stream (those seek failures have uncovered several bugs in std.stream). They checks had always been there
but
> since phobos is built in release mode the 'in' contracts and the asserts were turned off. One way that the problem could ahve been caught sooner is to have a non-release build on phobos. That would have helped. But it also got me thinking more about the purpose of 'in' contracts and the other contracts and asserts. It would be nice to have all parameter-checking in the 'in' contract and to _always_ compile in the 'in' contracts (well, ok, maybe give some special compiler option to not do any parameter checking). That way you always get parameter checking no matter if you turned off
'out'
> contracts (which check the logic of the function body) and invariants
(which
> check the internal logic of the system). Plus the parameter checking
> shouldn't assert but should throw a (currently non-existant)
ParamException.
> That way the parameter checking still happens even when the code is
compiled
> without asserts. The invariants and 'out' contracts should use asserts.
>
> Thoughts?
> -Ben
>
> ps - is there an easer way to say 'in' contract and 'out' contract? It looked wierd when I typed 'in' and 'out' without the quotes. Maybe I
should
> use pre-condition and post-condition.
>
>


April 17, 2005
"Kris" <fu@bar.com> wrote in message news:d3s0dv$d1h$1@digitaldaemon.com...
> From what I recall, there was at least one long thread on this very topic.

I also vaguely recall something started by Arcane Jill - or at least I remember her influence on the thread. I haven't looked it up, though. It had all kinds of good stuff about when to use asserts and contracts.

> The last time around, there seemed to be a general call for much more
> control over what the compiler generates/filters in terms of invariants,
> pre- & post-conditions, array bounds checking, etc. I got the impression
> the
> control would be handled via a set of compiler flags.

Makes sense. Mostly I want to have the in-contracts be the place to put parameter checking. It seems natural. The default "release" compiler setting IMO should compile 'in' contracts but not asserts, out-contracts or invariants. That would mean libraries could do parameter checking on user code.

> Did those requests fall on stony ground?

guess so.