--- Comment #22 from Don <> 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

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:
------- You are receiving this mail because: -------

Reply via email to