In short use `in(false)` when you `override` a function to inherit the contract, unless you explicitly want to expand the input - which you shouldn't do when implementing an interface!

Wrote about it in more details here:

http://dpldocs.info/this-week-in-d/Blog.Posted_2019_12_02.html

i think this is a pretty cool little discovery, thanks too for the folks on irc for chatting it through.

destroy if i missed anything lol

On Monday, 2 December 2019 at 20:30:49 UTC, Adam D. Ruppe wrote:
> Wrote about it in more details here:
>
> http://dpldocs.info/this-week-in-d/Blog.Posted_2019_12_02.html
>
> i think this is a pretty cool little discovery, thanks too for the folks on irc for chatting it through.

Interesting, could be useful, but now you have to remember to add "in(false)".

I wonder if this could somehow be wrapped up in a clean way using meta-programming so you always get the "in(false)"?

On Monday, 2 December 2019 at 22:31:08 UTC, Ola Fosheim Grøstad wrote:
> Interesting, could be useful, but now you have to remember to add "in(false)".

Yeah, it is kinda tempting to propose a language change, where an override method does this by default if nothing else is specified. I think it would probably usually be the right thing to do, and then you'd opt into extending it all the way by doing `in(true)` instead.

> I wonder if this could somehow be wrapped up in a clean way using meta-programming so you always get the "in(false)"?

I don't think so, contracts are invisible to reflection right now (unless there's a trick I don't know). Maybe a language change is warranted though, I don't really know, especially since this thing is possible today.

On Tuesday, 3 December 2019 at 02:57:13 UTC, Adam D. Ruppe wrote:
> On Monday, 2 December 2019 at 22:31:08 UTC, Ola Fosheim Grøstad wrote:
>> Interesting, could be useful, but now you have to remember to add "in(false)".
>
> Yeah, it is kinda tempting to propose a language change, where an override method does this by default if nothing else is specified. I think it would probably usually be the right thing to do, and then you'd opt into extending it all the way by doing `in(true)` instead.

Yes, I agree, if you forget to add a specification then it probably should have the same strictness as the superclass. That is what I would expect.

On 2019-12-03 07:53:48 +0000, Ola Fosheim Grøstad said:

> On Tuesday, 3 December 2019 at 02:57:13 UTC, Adam D. Ruppe wrote:
>> On Monday, 2 December 2019 at 22:31:08 UTC, Ola Fosheim Grøstad wrote:
>>> Interesting, could be useful, but now you have to remember to add "in(false)".
>> 
>> Yeah, it is kinda tempting to propose a language change, where an override method does this by default if nothing else is specified. I think it would probably usually be the right thing to do, and then you'd opt into extending it all the way by doing `in(true)` instead.
> 
> Yes, I agree, if you forget to add a specification then it probably should have the same strictness as the superclass. That is what I would expect.

+1 having to add something explicit to get the superclass contract activated looks weired.

In large scale projects this will become a big problem as you can't assume that every developer knows about all the contracts of a superclass.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On Tuesday, 3 December 2019 at 10:39:08 UTC, Robert M. Münch wrote:
> In large scale projects this will become a big problem as you can't assume that every developer knows about all the contracts of a superclass.

That's the beauty of `override in(false)` - you don't have to know about the superclass. You can use it and it works in all cases.

Though that's also a possible argument for the language change.

On 2019-12-03 13:00:49 +0000, Adam D. Ruppe said:

> On Tuesday, 3 December 2019 at 10:39:08 UTC, Robert M. Münch wrote:
>> In large scale projects this will become a big problem as you can't assume that every developer knows about all the contracts of a superclass.
> 
> That's the beauty of `override in(false)` - you don't have to know about the superclass. You can use it and it works in all cases.

My point was, when the superclass doesn't has an in() contract:

Error: function contracts.Derived.test cannot have an in contract when overridden function contracts.Base.test does not have an in contract

So, I need to know that the superclass has a contract and that I want to fallback to it. The former is the hard part.

> Though that's also a possible argument for the language change.

Yes, but only if the superclass has an in() contract.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On Tuesday, 3 December 2019 at 10:39:08 UTC, Robert M. Münch wrote:
> In large scale projects this will become a big problem as you can't assume that every developer knows about all the contracts of a superclass.

Yes, like if you just want to constrain a signed int to be >=1. If you forget to add it in the subclass it suddenly takes negative ints with no warning...

On Tuesday, 3 December 2019 at 14:24:15 UTC, Robert M. Münch wrote:
> My point was, when the superclass doesn't has an in() contract:
>
> Error: function contracts.Derived.test cannot have an in contract when overridden function contracts.Base.test does not have an in contract

ooooh geeze I was so focused on inheriting the contract that I didn't even test if it didn't have one at all. So we need a language change anyway.

ugh.

On Tuesday, 3 December 2019 at 14:40:21 UTC, Adam D. Ruppe wrote:
> ooooh geeze I was so focused on inheriting the contract that I didn't even test if it didn't have one at all. So we need a

Maybe also test with D interfaces? I suppose they have the same behaviour as superclasses?

Anyway, I think most programmers struggle with covariant/contravariant parameters... I certainly have to stop up and ponder for a while to figure out the semantics when hitting such. So I tend to avoid it... :-P :-)