You're Doing In-Conditions Wrong

[Steven Schveighoffer]

On 7/13/20 9:55 AM, FeepingCreature wrote:
> Reposting my bug report https://issues.dlang.org/show_bug.cgi?id=20628 
> here to generate some discussion.
> 
> tl;dr: D is handling in-contracts in a way that causes bad outcomes both 
> with and without debug mode, causing bizarre logic errors and even 
> accepting invalid syntax.

I think you mean, invalid code, not syntax. Invalid syntax will not pass 
the parser.

But I somewhat disagree. Yes, you can write bad contracts, but that is 
not on the compiler, and can't really be checked by the compiler. The 
compiler enforces the rule by ignoring what the derived class does if 
the parent class passes. It doesn't enforce the logic of your contract 
fits the rule.

However, the biggest problem I have with contract inheritance is that no 
contract means "ignore base contract". Why is this a problem? Because 
people are lazy and don't do things they don't have to.

If you do nothing, what are the chances that
   a) you know about the contract, and actively decided in(true) is the 
correct contract for your subtype, and also knew that not providing a 
contract was the equivalent of in(true) so just didn't write it.
   b) you forgot/didn't notice it.

IMO, an unstated contract should not alter the parent contract. Unstated 
code means "I didn't care" or "leave it the same". It's not an active 
decision to alter the contract drastically to "accept everything".

Possibly this means changing a base contract could cause problems with 
existing code. I'm OK with that, it is you changing the requirements for 
your users (the authors of the derived code).

However, it is tedious that one has to repeat all the super's contract 
if your additive contract is unrelated.

One possibility is to consider a way to say "everything super said and ..."

maybe like:

void foo(int i) in(super.in) in(i > 5) {}

-Steve