On 17/02/2012 05:08, Kapps wrote:
On Friday, 17 February 2012 at 03:24:50 UTC, Jonathan M Davis wrote:
On Thursday, February 16, 2012 18:49:40 Walter Bright wrote:
Given:
class A { void foo() { } }
class B : A { override pure void foo() { } }
This works great, because B.foo is covariant with A.foo, meaning it can
"tighten", or place more restrictions, on foo. But:
class A { pure void foo() { } }
class B : A { override void foo() { } }
fails, because B.foo tries to loosen the requirements, and so is not
covariant.
Where this gets annoying is when the qualifiers on the base class
function
have to be repeated on all its overrides. I ran headlong into this when
experimenting with making the member functions of class Object pure.
So it occurred to me that an overriding function could *inherit* the
qualifiers from the overridden function. The qualifiers of the
overriding
function would be the "tightest" of its explicit qualifiers and its
overridden function qualifiers. It turns out that most functions are
naturally pure, so this greatly eases things and eliminates annoying
typing.
I want do to this for @safe, pure, nothrow, and even const.
I think it is semantically sound, as well. The overriding function
body will
be semantically checked against this tightest set of qualifiers.
What do you think?
No. Absolutely not. I hate the fact that C++ does this with virtual.
It makes it so that you have to constantly look at the base classes to
figure out what's virtual and what isn't. It harms maintenance and
code understandability. And now you want to do that with @safe, pure,
nothrow, and const? Yuck.
I can understand wanting to save some typing, but I really think that
this harms code maintainability. It's the sort of thing that an IDE is
good for. It does stuff like generate the function signatures for you
or fill in the attributes that are required but are missing. I grant
you that many D developers don't use IDEs at this point (at least not
for D) and that those sort of capabilities are likely to be in their
infancy for the IDEs that we _do_ have, but I really think that this
is the sort of thing that should be left up to the IDE. Inferring
attribtutes like that is just going to harm code maintainibility. It's
bad enough that we end up with them not being marked on templates due
to inferrence, but we _have_ to do it that way, because the attributes
vary per instantiation. That is _not_ the case with class member
functions.
Please, do _not_ do this.
- Jonathan M Davis
In the situation where the IDE writes it for you, said IDE will help you
only when you write the code.
In the situation where the IDE tells you what they are (through
something like hovering over it), it will help you no matter who writes
the code. It is also significantly easier to implement, particularly
taking into consideration things like style, comments, etc.
Exactly. If one is worried about having to look at the base classes,
it's quite easy to check that info when you are using an IDE - for
example, with a hover over the overriding function which lists all the
parameters and attributes, and documentation too.
--
Bruno Medeiros - Software Engineer
