I don't disagree that tightening contracts for derived functions is a bad idea. I didn't mean the contract should fail, I meant that the program should fail with an error that the contract is invalid.
"Timon Gehr" <timon.g...@gmx.ch> wrote in message news:iuklvm$pks$1...@digitalmars.com... > Now, sure, if the parents contract is > > in{assert(a<=10);} > > and the child's contract is > > in{assert(a<=5);} > > then that is almost certainly an error because the child's contract fails > to > loosen any restrictions. > But to catch this in the general case, the compiler would have to > incorporate a > theorem prover. > (And validity of D code would start to depend on the quality of the > theorem prover > of the respective D compiler ;)) This can be caught at runtime without a theorem prover. (And I think it should be)
