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

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

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

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

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

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

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

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

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

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