--- Comment #17 from 2012-02-26 08:30:09 PST ---
(In reply to comment #16)
> (In reply to comment #15)
> > There is no "B's in". That is the point. The bug is that an implicit 'in'
> > contract that always passes is added to
> Yes that is the point. As no contract has been specified,

Wrong. The super class specifies a contract. This contract must be inherited.

> it is assumed that this function can accept anything.

That assumption is bogus, because this is almost never the case. It makes
contract programming basically unusable. Such a strong weakening of the 'in'
contract should not be the default.

> And so the implicit in contract alway
> succeed, so A's contract never get executed.
> Stewart Gordon already explained that and

I understand all of this, and the fact that it works that way is a bug.

> he is right.

He is right in that the implementation works that way. It shouldn't.

> However, Don's proposal make sense (defining how contract is executed at
> callee's place instead of caller's place).

Don's proposal is to remove 'in' contract widening completely. That does not
make a lot of sense to me.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to