You're Doing In-Conditions Wrong

[burt]

On Tuesday, 14 July 2020 at 12:05:23 UTC, FeepingCreature wrote:
> [...]
>
> I think the disagreement here is whether an incondition should 
> mean "a condition for the method" or "a condition that is added 
> to the implicit disjunction of the parent inconditions."
>
> I think the way that D works currently is bad. I'm raising a 
> design criticism here, not a bug - I know the current behavior 
> is per spec. But I mean, if you see
>
> ```
> class B : A {
>     void method(int x) in (x == 3) {}
> }
> ```
>
> You don't expect x to be 2. In fact, the vastly more plausible 
> way to arrive at this code is that the parent used to check `x 
> == 3` but was changed to check `x == 2`. The disjunctive 
> approach gives up the chance to discover this bug, for no 
> benefit. Why no benefit? To be frank, because this kind of 
> example essentially never comes up in practice.

So should the writer of a subclass HAVE to write out the 
preconditions of the parent? Because that could be impossible 
sometimes, if the precondition includes a call to a private 
function or something. Or perhaps some way to explicitly call the 
superclass's in contract.

> Something like 95% of inconditions in our codebase at least, 
> are some variant of "not null". How do you relax this 
> incondition? By not writing anything, in both proposals. You 
> certainly don't write `in (obj is null)`.

You could also write `in (true)` in the current state of affairs.

> When do you want to add an additional disjunctive check that is 
> totally unrelated to the parent's check? Even if you're say, 
> expanding an enum, the expanded check will simply be "is the 
> value in the expanded enum," not "is the value one of the two 
> new enum values that I added."
>
> I think "restate the parent's condition plus your new values" 
> is already what people do anyways. Might as well take advantage.

Is that sufficient for all cases? What if the superclass's 
precondition is `input1 == input2`, and the subclass's 
precondition also want to allow 
`input1.equalsCaseInsensitive(input2)` or something, how would 
you write that out?

-burt