On 29/02/2012 14:44, Timon Gehr wrote:
<snip>
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-programming-language.org or
dlang.org as I look at the moment.
<snip>
Anyway, probably it is not stated explicitly in the relevant parts of the spec
because it
is assumed that the reader is familiar with similar features in other languages.
Then it's a hole in the spec. If it's only meant to state how D differs from some other
language, it would have to state what language that is.
<snip>
Another scenario I've thought of is:
- library class defines a method with an in contract
- application class overrides this method, and has the same argument
restrictions as the library class
- a later version of the library class widens the range of acceptable
inputs
- however, the app's override is not prepared to deal with inputs that
are newly allowed by the API
...
This is not a contract-related problem. It is a breaking API change, whether or
not the
library class defines language level contracts.
How do you mean?
<snip>
Library writers shouldn't silently change functionality and/or redefine
interfaces.
<snip>
So you think that, once a library is written and released, no new functionality should
ever be added?
Stewart.
