• Ben Hinkle (27/27) Apr 16 2005 Some of my change in dmd-120 to std.stream got me thinking about 'in'
• Kris (17/44) Apr 16 2005 From what I recall, there was at least one long thread on this very topi...
• Ben Hinkle (10/17) Apr 16 2005 I also vaguely recall something started by Arcane Jill - or at least I

"Ben Hinkle" <ben.hinkle gmail.com> writes:

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. 

"Kris" <fu bar.com> writes:

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.

"Ben Hinkle" <ben.hinkle gmail.com> writes:

"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.