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
