You're Doing In-Conditions Wrong

[Timon Gehr]

On 15.07.20 14:00, Steven Schveighoffer wrote:
> 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.
> ...

Yes, this is broken.

> 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

Eiffel uses different syntax for require clauses on redefined features. 
"require else". In D, this would amount to something like:

override void foo()else in(i==3){ ... }