www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Is Override Still Mandatory?

reply "Vijay Nayar" <madric gmail.com> writes:
I was under the impression that the attribute "override" was 
mandatory when replacing a virtual function in a base class.  
However, code that leaves this out has no errors using dmd v2.060.

import std.stdio;

class A {
   this() {
     show();
   }
   void show() {
     writeln("A");
   }
}

class B : A {
   this() {
     super();
   }

   // No override and no compiler errors?
   void show() {
     writeln("B");
   }
}

void main() {
   auto b = new B();
   // This prints "B".
}

Also, is there a way to make class A call it's own version of 
show()?

  - Vijay
Nov 11 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, November 12, 2012 03:58:17 Vijay Nayar wrote:

 I was under the impression that the attribute "override" was
 mandatory when replacing a virtual function in a base class.
 However, code that leaves this out has no errors using dmd v2.060.


 
It's mandatory if you compile with -w. Eventually, it will be mandatory all 
the time. It's just that it's being phased in via -w rather than requiring it 
immediately. That way, people have time to fix their code to use it before it's 
required. Unfortunately though, a lot of people fail to compile with either -w 
or -wi, so they're happily writing _new_ code which will break once override 
is always required, which means that phasing like this doesn't necessarily 
actually fix the problem.

- Jonathan M Davis
Nov 11 2012
next sibling parent "Vijay Nayar" <madric gmail.com> writes:
Thanks for the info!  I'll start using -w for all my projects.
  - Vijay

On Monday, 12 November 2012 at 03:08:35 UTC, Jonathan M Davis 
wrote:

 On Monday, November 12, 2012 03:58:17 Vijay Nayar wrote:

 I was under the impression that the attribute "override" was
 mandatory when replacing a virtual function in a base class.
 However, code that leaves this out has no errors using dmd 
 v2.060.


 
 It's mandatory if you compile with -w. Eventually, it will be 
 mandatory all
 the time. It's just that it's being phased in via -w rather 
 than requiring it
 immediately. That way, people have time to fix their code to 
 use it before it's
 required. Unfortunately though, a lot of people fail to compile 
 with either -w
 or -wi, so they're happily writing _new_ code which will break 
 once override
 is always required, which means that phasing like this doesn't 
 necessarily
 actually fix the problem.

 - Jonathan M Davis
Nov 11 2012
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 Unfortunately though, a lot of people fail to compile with 
 either -w
 or -wi, so they're happily writing _new_ code which will break 
 once override
 is always required, which means that phasing like this doesn't 
 necessarily
 actually fix the problem.


I agree. Generally I think warnings should be active on default 
and disabled on request with a switch :-)

Bye,
bearophile
Nov 11 2012
parent reply "Rob T" <rob ucora.com> writes:
On Monday, 12 November 2012 at 03:29:09 UTC, bearophile wrote:

 I agree. Generally I think warnings should be active on default 
 and disabled on request with a switch :-)

 Bye,
 bearophile


Agreed! Fortunately I have not written all that much broken code 
yet. I recall a lot of discussion about how "depreciated" should 
work, and it's clear what we have now is next to useless, so I 
hope the suggestion that was made to improve depreciated with 
warnings and so forth, is implemented.

--rt
Nov 13 2012
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Rob T:


 so I hope the suggestion that was made to improve depreciated 
 with warnings and so forth, is implemented.


"Deprecated features as warnings" is in the D front since about 7 
hours:
https://github.com/D-Programming-Language/dmd/commit/5881617a34adc172b830314c17da21d5c834ffd0

Bye,
bearophile
Nov 13 2012
next sibling parent reply "Rob T" <rob ucora.com> writes:
On Wednesday, 14 November 2012 at 02:33:47 UTC, bearophile wrote:

 Rob T:


 so I hope the suggestion that was made to improve depreciated 
 with warnings and so forth, is implemented.


 "Deprecated features as warnings" is in the D front since about 
 7 hours:
 https://github.com/D-Programming-Language/dmd/commit/5881617a34adc172b830314c17da21d5c834ffd0

 Bye,
 bearophile


That's good news. If I were to use the latest pre-release version 
of dmd that was relatively safe, how will I find it, or is it OK 
to use the master branch?

--rt
Nov 13 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, November 14, 2012 07:59:06 Rob T wrote:

 That's good news. If I were to use the latest pre-release version
 of dmd that was relatively safe, how will I find it, or is it OK
 to use the master branch?


The master branch _is_ the pre-release version. dmd, druntime, and Phobos do 
not really use proper branches at this point (and even if they did, I wouldn't 
expect there to be a branch separate from master prior to a beta). It should 
be reasonably safe to use, but there's no telling how it will affect your code 
differently from the last release. At minimum there are several known 
regressions (which will be fixed prior to the next release), and there may be 
others. Personally, I use master all the time, but I'm one of the Phobos 
developers. It's fine if you use master (it could help us find regressions if 
nothing else), but I wouldn't really advise using it just to be able to use 
the -di flag.

Also, some of us are hoping that the change to deprecated will be reverted in 
favor of making it so that warnings will be the default for using deprecated 
symbols rather than having error be the default. Having -di is nice, but it 
really doesn't fix much. The main problem (at least from the library writer's 
point of view) is that deprecating anything instantly breaks the code of 
anyone using that the now deprecated symbol. -di makes it so that a programmer 
can protect themselves from that, but it still shackles the library writer 
such that they can't deprecate anything if they don't ever want to break 
anyone's code without giving more warning that a note in the changelog or 
documentation.

- Jonathan M Davis
Nov 14 2012
parent "Rob T" <rob ucora.com> writes:
On Wednesday, 14 November 2012 at 08:04:55 UTC, Jonathan M Davis 
wrote:
  but I'm one of

 the Phobos
 developers. It's fine if you use master (it could help us find 
 regressions if
 nothing else), but I wouldn't really advise using it just to be 
 able to use
 the -di flag.


There have been a few other recent bug fixes that have been 
giving me enough headaches for me to want to try it it out. By 
the looks of things, if I'm to make real use out of D, I'll have 
to learn how to fix D as well.


 Also, some of us are hoping that the change to deprecated will 
 be reverted in
 favor of making it so that warnings will be the default for 
 using deprecated


Yes, that's what makes the most sense.


 symbols rather than having error be the default. Having -di is 
 nice, but it
 really doesn't fix much. The main problem (at least from the 
 library writer's
 point of view) is that deprecating anything instantly breaks 
 the code of
 anyone using that the now deprecated symbol. -di makes it so 
 that a programmer
 can protect themselves from that, but it still shackles the 
 library writer
 such that they can't deprecate anything if they don't ever want 
 to break
 anyone's code without giving more warning that a note in the 
 changelog or
 documentation.


This subject always makes me think of Python, however, it also 
reminds me of the trap C++ fell into. Personally, I prefer 
dealing with a few breaking changes now and then rather than 
sticking with not-so-good decisions forever. In terms of man 
hours wasted, sticking with a poor design choice can eat up far 
more man hours over the years than the time taken to deal with a 
real fix. But I do understand both sides of the coin having been 
there myself. IMO, so long as you can stick with an older version 
of the compiler and library for legacy code, you're OK. You guys 
may want to ensure that older version of a library and compiler 
can easily co-exist on the same OS installation as a part of the 
solution to the deprecation breakage dilemma. If a programmer 
could choose both the compiler version, and a library version for 
importing into his source code, that would be excellent.

--rt
Nov 14 2012
prev sibling parent "Rob T" <rob ucora.com> writes:
On Wednesday, 14 November 2012 at 02:33:47 UTC, bearophile wrote:

 Rob T:


 so I hope the suggestion that was made to improve depreciated 
 with warnings and so forth, is implemented.


 "Deprecated features as warnings" is in the D front since about 
 7 hours:
 https://github.com/D-Programming-Language/dmd/commit/5881617a34adc172b830314c17da21d5c834ffd0

 Bye,
 bearophile


That's good news. If I were to use the latest pre-release version 
of dmd that was relatively safe, how will I find it, or is it OK 
to use the master branch?

--rt
Nov 13 2012
prev sibling parent "Rob T" <rob ucora.com> writes:
On Monday, 12 November 2012 at 03:08:35 UTC, Jonathan M Davis 
wrote:

 On Monday, November 12, 2012 03:58:17 Vijay Nayar wrote:

 I was under the impression that the attribute "override" was
 mandatory when replacing a virtual function in a base class.
 However, code that leaves this out has no errors using dmd 
 v2.060.


 
 It's mandatory if you compile with -w. Eventually, it will be 
 mandatory all
 the time. It's just that it's being phased in via -w rather 
 than requiring it
 immediately. That way, people have time to fix their code to 
 use it before it's
 required. Unfortunately though, a lot of people fail to compile 
 with either -w
 or -wi, so they're happily writing _new_ code which will break 
 once override
 is always required, which means that phasing like this doesn't 
 necessarily
 actually fix the problem.

 - Jonathan M Davis


I was about to ask this same question today! Thanks for the 
answer.

--rt
Nov 13 2012