http://d.puremagic.com/issues/show_bug.cgi?id=6856
timon.g...@gmx.ch changed:
What|Removed |Added
CC||adam.chrapkow...@gmail.com
---
http://d.puremagic.com/issues/show_bug.cgi?id=6856
--- Comment #24 from Don clugd...@yahoo.com.au 2012-02-27 22:14:03 PST ---
(In reply to comment #23)
(In reply to comment #22)
What this means in practice is that in contracts must be BEFORE the vtable
lookup, rather than being in the body
http://d.puremagic.com/issues/show_bug.cgi?id=6856
--- Comment #25 from timon.g...@gmx.ch 2012-02-27 23:28:16 PST ---
Yes, I think that works. The issue can be resolved by making the default 'in'
contract empty if the method is introduced without overriding another and
'assert(false)' if the
http://d.puremagic.com/issues/show_bug.cgi?id=6856
deadalnix deadal...@gmail.com changed:
What|Removed |Added
CC||deadal...@gmail.com
http://d.puremagic.com/issues/show_bug.cgi?id=6856
--- Comment #15 from timon.g...@gmx.ch 2012-02-26 05:11:34 PST ---
There is no B's in. That is the point. The bug is that an implicit 'in'
contract that always passes is added to B.foo.
--
Configure issuemail:
http://d.puremagic.com/issues/show_bug.cgi?id=6856
--- Comment #16 from deadalnix deadal...@gmail.com 2012-02-26 07:43:52 PST ---
(In reply to comment #15)
There is no B's in. That is the point. The bug is that an implicit 'in'
contract that always passes is added to B.foo.
Yes that is the
http://d.puremagic.com/issues/show_bug.cgi?id=6856
--- Comment #17 from timon.g...@gmx.ch 2012-02-26 08:30:09 PST ---
(In reply to comment #16)
(In reply to comment #15)
There is no B's in. That is the point. The bug is that an implicit 'in'
contract that always passes is added to B.foo.
http://d.puremagic.com/issues/show_bug.cgi?id=6856
--- Comment #18 from deadalnix deadal...@gmail.com 2012-02-26 08:46:45 PST ---
(In reply to comment #17)
Don's proposal is to remove 'in' contract widening completely. That does not
make a lot of sense to me.
Don's proposal is similar to
http://d.puremagic.com/issues/show_bug.cgi?id=6856
--- Comment #19 from Stewart Gordon s...@iname.com 2012-02-26 09:15:32 PST ---
(In reply to comment #17)
That assumption is bogus, because this is almost never the case.
It makes contract programming basically unusable. Such a strong
http://d.puremagic.com/issues/show_bug.cgi?id=6856
--- Comment #20 from timon.g...@gmx.ch 2012-02-26 10:30:17 PST ---
(In reply to comment #19)
(In reply to comment #17)
That assumption is bogus, because this is almost never the case.
It makes contract programming basically unusable.
http://d.puremagic.com/issues/show_bug.cgi?id=6856
Jesse Phillips jesse.k.phillip...@gmail.com changed:
What|Removed |Added
CC|
http://d.puremagic.com/issues/show_bug.cgi?id=6856
--- Comment #13 from Leandro Lucarella llu...@gmail.com 2011-11-03 07:26:39
PDT ---
(In reply to comment #12)
(In reply to comment #10)
(In reply to comment #9)
This explicit widening of preconditions of virtual functions seems to be a
http://d.puremagic.com/issues/show_bug.cgi?id=6856
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
---
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
http://d.puremagic.com/issues/show_bug.cgi?id=6856
--- Comment #11 from Leandro Lucarella llu...@gmail.com 2011-11-02 07:13:07
PDT ---
Oh, and I think it will also make more sense to first check the subclass
pre-condition (as it might be the wider one, and the one with more chances to
pass)
http://d.puremagic.com/issues/show_bug.cgi?id=6856
--- Comment #12 from Don clugd...@yahoo.com.au 2011-11-02 17:37:44 PDT ---
(In reply to comment #10)
(In reply to comment #9)
This explicit widening of preconditions of virtual functions seems to be a
really niche feature.
I think it
http://d.puremagic.com/issues/show_bug.cgi?id=6856
Leandro Lucarella llu...@gmail.com changed:
What|Removed |Added
CC||llu...@gmail.com
http://d.puremagic.com/issues/show_bug.cgi?id=6856
--- Comment #3 from Leandro Lucarella llu...@gmail.com 2011-11-01 05:27:32
PDT ---
BTW, that was DMD 1.071.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
http://d.puremagic.com/issues/show_bug.cgi?id=6856
--- Comment #4 from Leandro Lucarella llu...@gmail.com 2011-11-01 05:46:43
PDT ---
BTW, in contracts seems to be very ill defined, because overriding a method
with an in contract without specifying an in contract should inherit the
contract
http://d.puremagic.com/issues/show_bug.cgi?id=6856
--- Comment #5 from timon.g...@gmx.ch 2011-11-01 05:57:01 PDT ---
@Leandro: Your first example is okay. The precondition test shortcuts. It is
more or less equivalent to passes(X_foo_in) || passes(Y_foo_in). If
passes(X_foo_in), then the second
http://d.puremagic.com/issues/show_bug.cgi?id=6856
--- Comment #6 from timon.g...@gmx.ch 2011-11-01 05:59:14 PDT ---
(In reply to comment #4)
BTW, in contracts seems to be very ill defined, because overriding a method
with an in contract without specifying an in contract should inherit the
http://d.puremagic.com/issues/show_bug.cgi?id=6856
--- Comment #7 from Leandro Lucarella llu...@gmail.com 2011-11-01 09:50:56
PDT ---
OK, then the docs should be more clear I think, is really hard to infer this
behavior from the docs (unless someone explains it better :).
--
Configure
http://d.puremagic.com/issues/show_bug.cgi?id=6856
--- Comment #8 from Stewart Gordon s...@iname.com 2011-11-01 10:06:36 PDT ---
(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)?
http://d.puremagic.com/issues/show_bug.cgi?id=6856
Stewart Gordon s...@iname.com changed:
What|Removed |Added
CC||s...@iname.com
---
24 matches
Mail list logo
