Misleading contract syntax

Norbert Nemec Norbert at Nemec-online.de
Thu Mar 4 10:19:25 PST 2010


bearophile wrote:
> Complex enough different parts of the same program need "user interfaces" for each other, where the user is the programmer or another part of the program written by the programmer or another programmer. So libraries need to test all their inputs well anyway. I have programmed for enough years to be sure of this.
> So using preconditions based on asserts is not enough.

That's exactly why I plead for keeping apart the concepts "assertion" 
and "contract". It should be possible to deactivate the assertions 
inside a library and still keep the contracts active.

> But I don't like preconditions done with asserts, because any part of the program can receive wrong inputs from any other part of the code. So in functions/methods of my programs I will keep using exceptions to test inputs.

Exactly my point: contracts are not assertions.

Still, contracts are not exceptions either. A broken contract is a BUG. 
A triggered exception is a run-time condition that can happen in a 
perfectly correct program.

>> * A contract should *never* have side effects, otherwise debugging code may behave differently from release mode (which is the ultimate nightmare).<
> 
> I agree, but I have asked for something a little less strong, because I think it's enough and doesn't limit freedom too much:
> http://d.puremagic.com/issues/show_bug.cgi?id=3856

Not good enough. Any kind of side-effect should be prohibited. Demanding 
as side-effect free expression is the simplest way to achieve this.


>> * Any reasonable example with contracts contains just a list of assertions.<
> 
> I don't agree. There are many situations where you want to perform more computations...

Simply define a helper function. See other part of this thread.


>> => Why are contracts defined as lists of statements in the first place?<
> 
> Probably because Walter follows the very good engineering advice of keeping things simple. The current design is probably the simpler thing for the compiler, and it's good enough. I don't think the syntax needs to be changed.

Why should a statement be simpler for the compiler than an expression? 
It could even be implemented as attribute, simplifying the syntax.

Greetings,
Norbert



More information about the Digitalmars-d mailing list