Created attachment 1820 [details] Example I know that this has been reported as a bug before but it was declined as a bug. I reported it some years back also and I found two other similar reports issue-12227 and issue-21298. I continue to fall into this trap of this feature when I use an interface and nearly all of my colleagues which new to D fall into this. It is not logical that the pre/post-condition is not functional just because it comes from an interface. In my option, class C and CI should both execute the pre-condition, or at least the compiler should make an error and tell that preconditions are not allowed when the function is defined in an interface. ``` interface I { int func(int x); } class CI : I { int func(int x) in { assert(x > 0); } do { return x*x; } } class C { int func(int x) in { assert(x > 0); } do { return x*x; } } ``` Thank you for the good work.
Umm, contract programming is a system with goals and rules to achieve those goals. If you want to make assertions without much metaphysics, you can do it with assert expression: interface I { int func(int x); } class CI : I { int func(int x) { assert(x > 0); return x*x; } } I agree with issue 21298, restriction of the contract in the subtype is a programming mistake and should be rejected by the compiler.