http://d.puremagic.com/issues/show_bug.cgi?id=6856
--- Comment #22 from Don <clugd...@yahoo.com.au> 2012-02-27 02:44:28 PST --- (In reply to comment #17) > > 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. I did NOT propose that. I merely stated that it's a niche feature, because it only applies when calling a derived function directly, which is unusual behaviour. To restate: If you call any function f, your call MUST satisfy the in contracts of that function. If that function f has inherited a precondition from another function fbase, then the precondition may be weaker than the precondition of fbase. If f happens to ultimately be a call to fderived, with an even weaker precondition, that's irrelevant. You're not allowed to know that, it's an implementation detail -- you called f, not fderived. Only if you call fderived directly, are you allowed to take advantage of fderived's weaker precondition. I think that DMD's precondition widening algorithm may be OK. It can even be OK for fderived to have no in contract. That means, that if you call it *directly*, there are no rules about parameters. But, this should not obviate the callers requirements inherited from fbase. What this means in practice is that in contracts must be BEFORE the vtable lookup, rather than being in the body of the function. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------