View mode: basic / threaded / horizontal-split · Log in · Help
April 16, 2005
in contracts and param testing
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
Re: in contracts and param testing
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
Re: in contracts and param testing
"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.
Top | Discussion index | About this forum | D home