Created attachment 1820
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.
Comment #1 by dfj1esp02 — 2021-03-09T11:13:08Z
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.