--- Comment #23 from 2012-02-27 04:44:18 PST ---
(In reply to comment #22)
> (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.

It is not very unusual. It may be infrequent in some systems but it is not

> 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.

Yes, but in that case the existing contract from the overridden method must be
inherited. It is quite unusual that a child method has no constraints
whatsoever on its input when there were reasons to constrain the valid input to
the parent class.

> 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.

That is not what is wanted in practice.

> What this means in practice is that in contracts must be BEFORE the vtable
> lookup, rather than being in the body of the function.

Yes, that is issue 6857.

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

Reply via email to