https://issues.dlang.org/show_bug.cgi?id=6857
--- Comment #89 from Andrei Alexandrescu ---
To clarify: this issue is preapproved and is waiting for an implementation.
--
http://d.puremagic.com/issues/show_bug.cgi?id=6857
jens.k.muel...@gmx.de changed:
What|Removed |Added
CC||jens.k.muel...@gmx.de
--- Comme
http://d.puremagic.com/issues/show_bug.cgi?id=6857
deadalnix changed:
What|Removed |Added
CC||deadal...@gmail.com
--- Comment #2 from de
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #3 from jens.k.muel...@gmx.de 2012-03-02 00:35:52 PST ---
(In reply to comment #2)
> (In reply to comment #1)
> > Can you elaborate why the static type must be considered? What's the problem
> > with using the dynamic type?
>
> The
http://d.puremagic.com/issues/show_bug.cgi?id=6857
Don changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
--- Comment #4 from Don 2
http://d.puremagic.com/issues/show_bug.cgi?id=6857
timon.g...@gmx.ch changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
http://d.puremagic.com/issues/show_bug.cgi?id=6857
Walter Bright changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
http://d.puremagic.com/issues/show_bug.cgi?id=6857
timon.g...@gmx.ch changed:
What|Removed |Added
Resolution|INVALID |WONTFIX
--- Comment #8 from timon.g
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #10 from Walter Bright 2012-05-02
16:27:15 PDT ---
I suggest checking Bertrand Meyer's book Object-Oriented Software Construction,
which is the definitive reference on this. It's theoretically sound. I did not
invent the design, I
http://d.puremagic.com/issues/show_bug.cgi?id=6857
Andrei Alexandrescu changed:
What|Removed |Added
CC||and...@metalanguage.com
R
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #12 from deadalnix 2012-05-03 01:43:42 PDT ---
(In reply to comment #11)
> >The current specification is flawed. It have nothing to do with how
> >inheritance work (and I could assure you I know what I'm talking about, and
> >I'm
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #13 from Andrei Alexandrescu 2012-05-03
07:05:18 PDT ---
I apologize but I still think the confusion goes the other way. A good way to
arbiter this is to peruse the literature on the subject, as Walter suggested.
If going through a
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #14 from deadalnix 2012-05-03 10:45:19 PDT ---
(In reply to comment #13)
> I apologize but I still think the confusion goes the other way. A good way to
> arbiter this is to peruse the literature on the subject, as Walter suggested.
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #15 from Walter Bright 2012-05-03
11:07:27 PDT ---
fizbuzzA(A a) {
a.foo(); // A.foo's in contract is valid
}
If an instance of B is passed to fizbuzzA, then the a.foo() will call B.foo(),
and either A.foo's in contract or B.f
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #16 from Don 2012-05-03 11:56:47 PDT ---
(In reply to comment #15)
> fizbuzzA(A a) {
> a.foo(); // A.foo's in contract is valid
> }
>
> If an instance of B is passed to fizbuzzA, then the a.foo() will call B.foo(),
> and either
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #17 from deadalnix 2012-05-03 13:44:36 PDT ---
(In reply to comment #15)
> fizbuzzA(A a) {
> a.foo(); // A.foo's in contract is valid
> }
>
> If an instance of B is passed to fizbuzzA, then the a.foo() will call B.foo(),
> and
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #18 from Walter Bright 2012-05-03
15:37:00 PDT ---
(In reply to comment #17)
> As you can see in given code, fizbuzzA is an invalid piece of code waiting to
> explode in your face.
There is no bug in example #14. Please show one w
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #19 from Walter Bright 2012-05-03
15:46:03 PDT ---
(In reply to comment #16)
> This is the issue. WHY are they done based on the virtual type?
> Checking the contracts based on static typing would detect logical errors in
> the cal
http://d.puremagic.com/issues/show_bug.cgi?id=6857
Stewart Gordon changed:
What|Removed |Added
CC||s...@iname.com
--- Comment #20 from S
http://d.puremagic.com/issues/show_bug.cgi?id=6857
Stewart Gordon changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
http://d.puremagic.com/issues/show_bug.cgi?id=6857
Walter Bright changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #23 from Stewart Gordon 2012-05-03 18:21:44 PDT ---
(In reply to comment #22)
>> If you mean whether a given call is legal, then you could by the
>> same argument insist that called method names must be resolved in
>> the context
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #24 from Walter Bright 2012-05-03
18:50:03 PDT ---
(In reply to comment #23)
> (In reply to comment #22)
> >> If you mean whether a given call is legal, then you could by the
> >> same argument insist that called method names must
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #25 from Stewart Gordon 2012-05-03 19:02:13 PDT ---
(In reply to comment #24)
> No, I'm not. This thread is about overriding, not introducing, functions.
It's about introducing new legal inputs to a function. Which is conceptuall
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #26 from deadalnix 2012-05-04 01:46:25 PDT ---
(In reply to comment #22)
> You cannot widen the requirements of a function without providing an override
> of it. A.foo() cannot be called with the widened requirements of B.foo() -
>
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #27 from Andrei Alexandrescu 2012-05-04
04:03:36 PDT ---
(In reply to comment #26)
> No it isn't. OOP doesn't say anything about contracts. The concept of contract
> is different and the question here is how both interact in a spec
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #28 from Don 2012-05-04 04:48:20 PDT ---
(In reply to comment #27)
> (In reply to comment #26)
> There's no reason to doubt you are telling the truth, so this must be quite an
> interesting case of confirmation bias as you seem to h
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #29 from Andrei Alexandrescu 2012-05-04
05:35:12 PDT ---
(In reply to comment #28)
> > The literally FIRST hit takes to a slide deck, see http://goo.gl/544fU.
> > There
> > there is theory and examples on how contracts work.
>
>
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #30 from Don 2012-05-04 05:57:39 PDT ---
(In reply to comment #29)
> (In reply to comment #28)
> > > The literally FIRST hit takes to a slide deck, see http://goo.gl/544fU.
> > > There
> > > there is theory and examples on how cont
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #31 from Andrei Alexandrescu 2012-05-04
06:21:14 PDT ---
(In reply to comment #30)
> You are making a massive assumption here, which I don't see in the slides. The
> assumption is that fizzbuzz gets access to B's weakened precondit
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #32 from Stewart Gordon 2012-05-04 10:38:33 PDT ---
(In reply to comment #30)
> fizzbuzz() clearly has a bug. It will fail if given an A which isn't actually
> a
> B.
Exactly. fizzbuzz is calling a method of A, not a method of B.
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #33 from Walter Bright 2012-05-04
11:42:40 PDT ---
(In reply to comment #32)
> (In reply to comment #30)
> > fizzbuzz() clearly has a bug. It will fail if given an A which isn't
> > actually a
> > B.
>
> Exactly. fizzbuzz is cal
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #34 from Stewart Gordon 2012-05-04 13:27:50 PDT ---
(In reply to comment #33)
OK, so there's this issue. It may also be a documented guarantee that the
return value from bar is a valid argument for foo.
But you could still argue t
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #35 from Walter Bright 2012-05-04
13:41:50 PDT ---
(In reply to comment #34)
> But you could still argue that the call is in breach of A's API and therefore
> the code is incorrect.
Again, this is NOT true. The type of the argumen
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #36 from Stewart Gordon 2012-05-04 13:49:11 PDT ---
(In reply to comment #35)
> Again, this is NOT true. The type of the argument is not statically
> A, it is a polymorphic type A.
Why do you consider the contracts of a method to
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #37 from Walter Bright 2012-05-04
14:13:50 PDT ---
(In reply to comment #36)
> (In reply to comment #35)
>
> > Again, this is NOT true. The type of the argument is not statically
> > A, it is a polymorphic type A.
>
> Why do you
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #38 from Stewart Gordon 2012-05-04 14:30:40 PDT ---
(In reply to comment #37)
> Then I am lost as to what you think is broken in the design.
In how many different ways does the same thing need to be explained to you
before you unde
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #39 from Walter Bright 2012-05-04
14:46:11 PDT ---
Please write a piece of code that asserts when it should not, or passes when it
should not, compile it, verify this incorrect behavior, and post it here.
--
Configure issuemail:
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #40 from Stewart Gordon 2012-05-04 14:52:44 PDT ---
(In reply to comment #39)
> Please write a piece of code that asserts when it should not, or passes when
> it
> should not, compile it, verify this incorrect behavior, and post it
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #41 from Walter Bright 2012-05-04
15:18:08 PDT ---
(In reply to comment #40)
> (In reply to comment #39)
> > Please write a piece of code that asserts when it should not, or passes
> > when it
> > should not, compile it, verify th
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #42 from Stewart Gordon 2012-05-04 15:27:45 PDT ---
(In reply to comment #41)
> Example #1 expects behavior based on the static type, which is not polymorphic
> OOP at all.
True, but it is what this enhancement request is all about
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #43 from Walter Bright 2012-05-04
17:40:19 PDT ---
(In reply to comment #42)
> True, but it is what this enhancement request is all about.
Breaking correct OOP behavior is not an enhancement. It will not break existing
wrong-but-j
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #44 from Stewart Gordon 2012-05-04 17:50:19 PDT ---
(In reply to comment #43)
> (In reply to comment #42)
>> True, but it is what this enhancement request is all about.
>
> Breaking correct OOP behavior is not an enhancement.
But
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #45 from Walter Bright 2012-05-04
18:18:11 PDT ---
(In reply to comment #44)
> But going by comment 26, there is no breakage of correct OOP behaviour
> involved. So how is this relevant?
This has already been covered. We're going
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #46 from Don 2012-05-04 22:58:38 PDT ---
(In reply to comment #45)
> (In reply to comment #44)
> > But going by comment 26, there is no breakage of correct OOP behaviour
> > involved. So how is this relevant?
>
> This has already
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #47 from Walter Bright 2012-05-05
02:02:48 PDT ---
(In reply to comment #46)
> Now, change F from a struct to a class. We believe that the code should still
> fail to compile.
A theorem prover could not produce a compile time erro
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #47 from Walter Bright 2012-05-05
02:02:48 PDT ---
(In reply to comment #46)
> Now, change F from a struct to a class. We believe that the code should still
> fail to compile.
A theorem prover could not produce a compile time erro
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #49 from Stewart Gordon 2012-05-05 04:40:48 PDT ---
(In reply to comment #47)
> (In reply to comment #46)
> > Now, change F from a struct to a class. We believe that the code should
> > still
> > fail to compile.
>
> A theorem pro
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #50 from deadalnix 2012-05-05 05:04:07 PDT ---
(In reply to comment #33)
> (In reply to comment #32)
> > (In reply to comment #30)
> > > fizzbuzz() clearly has a bug. It will fail if given an A which isn't
> > > actually a
> > > B.
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #51 from deadalnix 2012-05-05 06:22:21 PDT ---
(In reply to comment #49)
> Runtime polymorphism is about overriding behaviour, not overriding legality.
>
This is, indeed, the whole essence of the problem.
(In reply to comment #48
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #52 from Andrei Alexandrescu 2012-05-05
08:54:17 PDT ---
(In reply to comment #51)
> I'm sorry, but this reading can't close the discussion.
I think it does. The proposed behavior does not allow this:
"None of this, then, is perm
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #53 from deadalnix 2012-05-05 08:58:21 PDT ---
(In reply to comment #52)
> (In reply to comment #51)
> > I'm sorry, but this reading can't close the discussion.
>
> I think it does. The proposed behavior does not allow this:
>
> "
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #54 from Stewart Gordon 2012-05-05 09:21:02 PDT ---
(In reply to comment #52)
> Doing a better job is succeeding where the parent method would have failed its
> precondition. It all boils down to the fact that it's natural to have m
http://d.puremagic.com/issues/show_bug.cgi?id=6857
Walter Bright changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #56 from Don 2012-05-06 00:36:04 PDT ---
(In reply to comment #55)
> Mea culpa.
>
> I read Meyer's book again. Chapter 16.1 "Cutting out the middleman" pg. 575
> says:
>
> "A client of MATRIX must satisfy the original (stronger) p
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #57 from deadalnix 2012-05-06 02:20:47 PDT ---
(In reply to comment #55)
> So I'm reopening it as a normal bug.
>
Thank you !
> Unfortunately, I do not currently see a reasonable way of implementing this.
> Fortunately, as is it
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #59 from deadalnix 2012-05-06 03:27:45 PDT ---
(In reply to comment #58)
> It's not that simple. Several considerations have to be met:
>
> 1. Because of struct construction/destruction, you really only want to
> construct the para
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #60 from Andrei Alexandrescu 2012-05-06
19:48:55 PDT ---
This has been some significant pwning of Walter and myself, and I think there
is a larger lesson here we should learn.
We essentially operated from vague memories instead of
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #61 from Stewart Gordon 2012-05-07 03:58:47 PDT ---
(In reply to comment #58)
> It's not that simple. Several considerations have to be met:
>
> 1. Because of struct construction/destruction, you really only
> want to construct t
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #62 from deadalnix 2012-05-07 04:43:25 PDT ---
(In reply to comment #60)
> This has been some significant pwning of Walter and myself, and I think there
> is a larger lesson here we should learn.
>
Quoting yourself � Mistakes happ
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #63 from Walter Bright 2012-05-07
08:29:21 PDT ---
(In reply to comment #61)
> (In reply to comment #58)
> > It's not that simple. Several considerations have to be met:
> >
> > 1. Because of struct construction/destruction, you
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #64 from deadalnix 2012-05-07 09:00:05 PDT ---
(In reply to comment #63)
> Again, you're pushing the parameters on the stack twice - and this won't work
> for variadic functions.
Why not jump in the function directly after the pro
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #65 from Walter Bright 2012-05-07
09:36:56 PDT ---
(In reply to comment #64)
> Why not jump in the function directly after the prolog and not push arguments
> twice on the stack ?
Not so easy given how back ends are designed.
--
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #66 from Stewart Gordon 2012-05-07 10:32:33 PDT ---
(In reply to comment #63)
> > Can't this be solved by simply making all struct parameters to the in/out
> > functions ref?
>
> Losing all C ABI compatiblity in the process.
Contr
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #67 from Stewart Gordon 2012-05-07 10:48:26 PDT ---
(In reply to comment #62)
> Changing how the language work must be done only if strong arguments are made.
Unless I've missed something, the language leaves this unspecified. So
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #68 from Walter Bright 2012-05-07
12:17:19 PDT ---
(In reply to comment #66)
> (In reply to comment #63)
> > > Can't this be solved by simply making all struct parameters to the in/out
> > > functions ref?
> >
> > Losing all C ABI
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #69 from Stewart Gordon 2012-05-07 12:26:47 PDT ---
(In reply to comment #68)
> 1. pass by ref is semantically very different from pass by value. It is
> necessary to support both.
The function that implements a contract is an inte
http://d.puremagic.com/issues/show_bug.cgi?id=6857
David Piepgrass changed:
What|Removed |Added
CC||qwertie...@gmail.com
--- Comment #70
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #71 from deadalnix 2012-07-08 14:50:57 PDT ---
The error is in the fact that addAll isn't aware of B.
You can solve that easily with metaprograming, or by overloading addAll for B.
--
Configure issuemail: http://d.puremagic.com/i
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #72 from timon.g...@gmx.ch 2012-07-08 14:58:07 PDT ---
(In reply to comment #70)
> I must say, I would be entirely opposed to fixing this "bug". As far as I can
> see, the arguments of Timon and deadalnix have been entirely theoretic
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #73 from timon.g...@gmx.ch 2012-07-08 15:08:47 PDT ---
(In reply to comment #70)
>
> P.S. Besides which, the implementation difficulties mentioned by Walter in
> comment 58 are really big difficulties, that don't seem worth it for w
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #74 from Stewart Gordon 2012-07-08 15:59:47 PDT ---
(In reply to comment #72)
> (In reply to comment #70)
>> // BTW I wanted to use an interface here, but I get
>> // "missing body { ... } after in or out"
>> // and then if I add a
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #75 from David Piepgrass 2012-07-08 17:05:28
PDT ---
> > I must say, I would be entirely opposed to fixing this "bug". As far as I
> > can
> > see, the arguments of Timon and deadalnix have been entirely theoretical,
>
> It is ir
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #76 from yebblies 2012-07-10 02:54:06 EST ---
(In reply to comment #55)
>
> Unfortunately, I do not currently see a reasonable way of implementing this.
> Fortunately, as is it does not inhibit correct programs, it only accepts som
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #77 from Stewart Gordon 2012-07-09 11:12:52 PDT ---
(In reply to comment #76)
> I can't see any way to do it without changing the abi for virtual functions
> with contracts.
What about my suggestion of comment 61?
--
Configure is
http://d.puremagic.com/issues/show_bug.cgi?id=6857
yebblies changed:
What|Removed |Added
CC||yebbl...@gmail.com
--- Comment #78 from yeb
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #79 from Stewart Gordon 2012-07-09 15:22:23 PDT ---
(In reply to comment #78)
> As Walter said, that requires argument forwarding, which introduces copying
> problems and doesn't work with variadics.
I thought I'd debunked that, bu
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #80 from yebblies 2012-07-10 14:02:54 EST ---
(In reply to comment #79)
> (In reply to comment #78)
> But it does seem to be down to two problems with D's design:
> - structs aren't guaranteed to be safe to just bit-copy (this probl
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #81 from Stewart Gordon 2012-07-10 05:05:48 PDT ---
(In reply to comment #80)
> (In reply to comment #79)
>> - we have variadics that are really just C's variadics with
>> typeinfo added
>
> We also have C's variadics.
But no use
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #82 from yebblies 2012-07-10 22:50:07 EST ---
(In reply to comment #81)
> (In reply to comment #80)
> > (In reply to comment #79)
> >> - we have variadics that are really just C's variadics with
> >> typeinfo added
> >
> > We also
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #83 from Stewart Gordon 2012-07-10 15:47:32 PDT ---
(In reply to comment #82)
> (In reply to comment #81)
>> But no use case I can see for using a C-style variadic for a D class method.
>
> I dunno, maybe you want to pass the args
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #84 from Andrei Alexandrescu 2012-09-05
07:24:44 PDT ---
Created an attachment (id=1143)
Inherited contracts
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail becaus
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #86 from Andrei Alexandrescu 2012-09-05
07:27:40 PDT ---
Forgot to mention - I attached the relevant page from the book (Walter found
it) that makes it as clear as it gets how inherited preconditions should
behave.
--
Configure i
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #85 from Andrei Alexandrescu 2012-09-05
07:26:07 PDT ---
I've had the opportunity to discuss the matter with Bertrand Meyer himself and
with a graduate student of his. Bertrand didn't have a defined answer offhand,
but opined that
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #87 from deadalnix 2013-01-10 00:41:57 PST ---
(In reply to comment #85)
> I've had the opportunity to discuss the matter with Bertrand Meyer himself and
> with a graduate student of his. Bertrand didn't have a defined answer offhan
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #88 from Andrei Alexandrescu 2013-01-10
09:14:02 PST ---
@Walter: would you preapprove this?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
https://issues.dlang.org/show_bug.cgi?id=6857
Iain Buclaw changed:
What|Removed |Added
Priority|P2 |P3
--
On Saturday, 5 May 2012 at 05:57:31 UTC, Don wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #46 from Don 2012-05-04
22:58:38 PDT ---
(In reply to comment #45)
(In reply to comment #44)
> But going by comment 26, there is no breakage of correct OOP
> behaviour
> inv
Please reply on bugzilla, replying here is most likely to be overlooked.
On 5/6/2012 2:19 AM, d-bugm...@puremagic.com wrote:
That is not this complicated. you need a final function that check the in
contract, then call another virtual function that actually execute the function
body and the out contract.
With such a configuration, the in contract is checked and only
90 matches
Mail list logo
