How do I use in contract with interface?

[Steven Schveighoffer]

On 11/15/17 10:39 AM, Jonathan M Davis wrote:
> 
> Well, the rules do make sense when you consider that it can make sense for a
> function to allow arguments that the base class didn't. The in contract is
> essentially saying what the function can validly operate on, and there's no
> reason why a derived class couldn't work with more values than the base
> class could. So, the loosening makes sense when you think about it. It just
> means that if you're trying to have a contract that you put in one place and
> then gets reused rather than having to repeat it in each derived class, then
> in contracts don't really work. For that, it makes more sense to use NVI so
> that the in contract is on the public base class or interface function, and
> the protected, derived functions that the public function calls then don't
> actually have any in contracts.

Loosening does make sense, and I'm not opposed to it.

But what doesn't make a lot of sense is the inability to declare the 
inheritance of the current in-contract situation. If you have a complex 
contract, then having to repeat it on every class seems unnecessarily 
verbose. It's very easy to just say `in {}` if you now can accept all 
possible parameters. The opposite is not as easy.

-Steve