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



--- Comment #10 from Leandro Lucarella <llu...@gmail.com> 2011-11-02 07:11:42 
PDT ---
(In reply to comment #9)
> This explicit widening of preconditions of virtual functions seems to be a
> really niche feature.

I think it does makes some sense to be like this. You can see it as adding an
extra method to a derived class, or class implementing an interface. The
derived class adding a new method() still satisfies the interface, in the same
sense an overriden method accepting wider preconditions still satisfies the
original precondition, and the interface.

The problem for me is:

1) The docs are not very clear about that. I didn't understood they worked like
this until now, that some change in the compiler triggered an error on a "in"
contract in Tango. I don't think I'm the only one misunderstanding contracts,
as when I took a look at the code pre-conditions was wrongly used all over it.

2) There seem to be bugs in the implementation. For example in this Tango bug
report: http://www.dsource.org/projects/tango/ticket/2067, the sync() method is
OK to trigger the error because it comes from an interface with no
preconditions, but the close() error seems to be wrong, as the parent class
also has a precondition on that method. I didn't have the time to try to come
up with a minimal testcase yet, sorry.

Also, see this example:
extern (C) int printf(char* s, ...);

class X
{
    void f(bool failx = false, bool faily = false)
    in { printf("\tX.f() in: assert(%d)\n", !failx); assert(!failx); }
    body {}
}

class Y : X
{
    override void f(bool failx = false, bool faily = false)
    in { printf("\tY.f() in: assert(%d)\n", !faily); assert(!faily); }
    body {}
}

class Z : Y
{
    override void f(bool failx = false, bool faily = false)
    in { printf("\tZ.f() in: assert(0)\n");  assert(false); }
    body {}
}

void main()
{
    printf("--------------------\n");
    printf("Z z\n");
    Z z = new Z;
    z.f(true, true);
    printf("\t---\n");
}

This is the output:
--------------------
Z z
    Y.f() in: assert(1)
    ---

Is there any good reason why suddenly faily gets set to false when true was
passed? If this is confirmed as a bug I'll create another ticket.

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

Reply via email to