You're Doing In-Conditions Wrong

[Steven Schveighoffer]

On 7/16/20 2:26 AM, FeepingCreature wrote:
> On Wednesday, 15 July 2020 at 12:00:49 UTC, Steven Schveighoffer wrote:
>> Why is not requiring you to restate the base code contract a bad intent?
> 
> Because it solves a problem that, as far as I can tell from our codebase 
> which uses inconditions basically everywhere, doesn't exist.

If it doesn't do it this way, then the possibility exists that the 
derived class doesn't allow inputs that the base class does. Yes, you 
can test for it, but tests don't always prove the rule holds (if you 
don't test the right inputs). However, the current implementation 
*guarantees* that the rule holds, even if you don't properly handle it 
in your subcontract.

I agree that the way derived contracts are implemented, it's very 
difficult to see what the "actual" contract really is, because you have 
to scan through the entire object hierarchy to see what the full 
contract entails.

It's like having an if/else statement spread out over several modules.

> 
> I have, to my recollection, *never* wanted to loosen an incondition by 
> adding a totally unrelated condition that can't be written as a 
> different phrasing of the parent incondition. And we have, uh, *counts* 
> ~4.3k inconditions. (Of which 3.7k are some variant of "is not null" 
> tests.) Shouldn't D focus on the common case?

I can see this being likely, but one project or organizational ecosystem 
is not proof that it doesn't exist. Every time I think "nobody would 
write code like this" and push to get rid of or change a feature, 
someone complains. There was e.g. significant resistance to getting rid 
of the comma operator.

I don't have a good answer. I don't know that implementing the contracts 
differently is going to achieve a better outcome. But I understand that 
the current situation is not ideal.

-Steve