There's been a lot of debate about the inheritance of in contracts, in particular what's
supposed to happen if a method in a base class has an in contract and its override doesn't.
http://d.puremagic.com/issues/show_bug.cgi?id=6856
The spec isn't explicit on whether the overridden method retains
On 02/29/2012 03:06 PM, Stewart Gordon wrote:
There's been a lot of debate about the inheritance of in contracts, in
particular what's supposed to happen if a method in a base class has an
in contract and its override doesn't.
http://d.puremagic.com/issues/show_bug.cgi?id=6856
The spec isn't exp
On 29/02/2012 14:44, Timon Gehr wrote:
The spec isn't explicit on whether the overridden method retains the
base's in contract unchanged or loses its in contract altogether.
The front page of the web site is quite explicit about this:
What web site? Certainly not www.digitalmars.com or d-pr
On 02/29/2012 05:26 PM, Stewart Gordon wrote:
On 29/02/2012 14:44, Timon Gehr wrote:
The spec isn't explicit on whether the overridden method retains the
base's in contract unchanged or loses its in contract altogether.
The front page of the web site is quite explicit about this:
What web s
Le 29/02/2012 17:26, Stewart Gordon a écrit :
So you think that, once a library is written and released, no new
functionality should ever be added?
We are reaching the discussion of evolving API.
I do think that if change such a thing, you should rename your function
to express its new functi
On 29/02/2012 17:01, Timon Gehr wrote:
The official website, d-programming-language.org or dlang.org. You have to click on
"See
example". It is at the first bulb of "Power".
But the comment "// <-- assumed to inherit contract" isn't actually there, so what's
"quite explicit" about it? Besid
On 02/29/2012 07:06 PM, Stewart Gordon wrote:
On 29/02/2012 17:01, Timon Gehr wrote:
The official website, d-programming-language.org or dlang.org. You
have to click on "See
example". It is at the first bulb of "Power".
But the comment "// <-- assumed to inherit contract" isn't actually
there
On 29/02/2012 19:24, Timon Gehr wrote:
That was just for documentation... The part that is explicit is:
// Single inheritance of state
class ExtendedWidget : Widget {
override void print(uint level)
in { /* weakening precondition is okay */ } body {
... level may be 0 here ...
}
}
The fact tha
On 02/29/2012 09:30 PM, Stewart Gordon wrote:
On 29/02/2012 19:24, Timon Gehr wrote:
That was just for documentation... The part that is explicit is:
// Single inheritance of state
class ExtendedWidget : Widget {
override void print(uint level)
in { /* weakening precondition is okay */ } body
On Wednesday, February 29, 2012 21:45:19 Timon Gehr wrote:
> On 02/29/2012 09:30 PM, Stewart Gordon wrote:
> > So what? It's a bug that compiler behaviour doesn't match the
> > documentation. You seem to be agreed that this is the case with what
> > happens to the contract where the override has no
On 29/02/2012 20:45, Timon Gehr wrote:
On 02/29/2012 09:30 PM, Stewart Gordon wrote:
But I can see what you really mean: the spec of what inputs to an
overridable function are legal and what inputs are illegal is part of
the API.
Stewart.
An input that is not legal is illegal and vice-versa
On 03/01/2012 01:49 AM, Stewart Gordon wrote:
On 29/02/2012 20:45, Timon Gehr wrote:
On 02/29/2012 09:30 PM, Stewart Gordon wrote:
But I can see what you really mean: the spec of what inputs to an
overridable function are legal and what inputs are illegal is part of
the API.
Stewart.
An in
12 matches
Mail list logo
