You're Doing In-Conditions Wrong
burt
invalid_email_address at cab.abc
Tue Jul 14 13:28:06 UTC 2020
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
More information about the Digitalmars-d
mailing list