You're Doing In-Conditions Wrong

[Steven Schveighoffer]

On 7/15/20 12:17 AM, FeepingCreature wrote:
> On Tuesday, 14 July 2020 at 16:09:59 UTC, Steven Schveighoffer wrote:
>> On 7/14/20 11:37 AM, FeepingCreature wrote:
>>> On Tuesday, 14 July 2020 at 13:37:58 UTC, Steven Schveighoffer wrote:
>>>> 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.
>>>>
>>>
>>> It can be checked by the compiler just fine at runtime. IMO, this is 
>>> what unittests are for.
>>
>> But the derived contracts are intended to be used only if the base 
>> contract fails. It's not entirely inappropriate or unheard of to write 
>> such a contract with that in mind.
>>
> 
> Right, I agree that this is what it's intended for, I just think that's 
> a bad intent.

Why is not requiring you to restate the base code contract a bad intent? 
Note that the restating would have to be done carefully, as you don't 
want to fail the derived contract in cases where you have loosened the 
requirements.

> It's not *entirely* inappropriate or unheard to write such 
> a contract, but I do think it's *almost* entirely inappropriate and 
> unheard. Do you have any practical examples, not contrived i==3 cases?

My knowledge is only theoretical -- I never use contracts, just in-code 
asserts. And I rarely use classes anyway.

However, any time I have used contracts, I have gotten frustrated with 
how they disappear because code authors (mostly me) forget to include 
them on the derived types. They might get used more if they weren't so 
easy to get rid of.

I get what you are saying -- having a contract right in front of you 
that is seemingly violated is confusing and unintuitive, even if it is 
correct. I don't know a good answer, but I don't like the idea of 
requiring less DRY code.

-Steve