[Issue 6856] Preconditions are not inherited

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=6856


Don <clugdbug at yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug at yahoo.com.au


--- Comment #9 from Don <clugdbug at yahoo.com.au> 2011-11-02 01:30:27 PDT ---
(In reply to comment #8)
> (In reply to comment #2)
> > Shouldn't "Y y" print "Y.f()" if Y can loose the in contract?
> > Shouldn't "X z" and "Y z" print *something* (probably "X.f()" and "Y.f()"
> > respectively)?
> 
> Only one of the contracts needs to pass for the overall contract to pass.  So
> once it's tried one and found that it's passed, it doesn't need to try the
> others.
> 
> When you have a Y, it first tries X's in contract.  This passes, so it doesn't
> need to check Y's as well.  Of course, an implementation could just as well
> check Y's contract first and then fall back to X's if that fails.
> 
> But because Z's in contract is empty, the compiler just optimises away the
> whole contract checking.

I'm a little confused by the relationship between this bug and bug 6857.
If you accept 6857, then if you call a function f() from a base class B, only
the precondition of the base class should matter. Although one derived class
C.f() may accept a weaker precondition, the caller doesn't actually know it had
a C, so it's making an unwarranted assumption.

So, if you accept that, then contracts in derived classes don't matter unless
they are called directly.

That's really odd, because you have a single function which has two different
semantic guarantees depending on who is calling it.
Following this through, I don't see the need for explicit widening of
preconditions at all. If we didn't have the feature, and you needed it (which I
believe happens very rarely), you could just create a separate function g() for
the direct calls, and give _it_ the weaker contract. The derived function f()
can just call g(). If you need to rely on the weaker contract, call g() instead
of f(). Easy to implement, easy to understand.

This explicit widening of preconditions of virtual functions seems to be a
really niche feature.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------