Bug 11616 – Introduce virtual keyword and remove virtual-by-default

Thread with discussion and Walter-approval: http://forum.dlang.org/thread/[email protected]?page=28#post-koqkhc:244nn:241:40digitalmars.com 1. Add warning for not marking a virtual method with 'virtual' 2. Deprecate not marking a virtual method with 'virtual' 3. Make it an error to not mark virtual methods with 'virtual' At this point, all methods are marked with either 'virtual', 'final', 'abstract', or 'override' or are implicitly final. (eg template methods, constructors) 4. Do not require 'final' to mark a function as final. (optional)

(In reply to comment #0) > Thread with discussion and Walter-approval: > > http://forum.dlang.org/thread/[email protected]?page=28#post-koqkhc:244nn:241:40digitalmars.com > > 1. Add warning for not marking a virtual method with 'virtual' > 2. Deprecate not marking a virtual method with 'virtual' > 3. Make it an error to not mark virtual methods with 'virtual' > > At this point, all methods are marked with either 'virtual', 'final', > 'abstract', or 'override' or are implicitly final. (eg template methods, > constructors) > > 4. Do not require 'final' to mark a function as final. (optional) Since I already started writing this, I may as well paste it here: http://wiki.dlang.org/DIP51 It can be updated if details emerge.

(In reply to comment #1) > (In reply to comment #0) > > Thread with discussion and Walter-approval: > > > > http://forum.dlang.org/thread/[email protected]?page=28#post-koqkhc:244nn:241:40digitalmars.com > > > > 1. Add warning for not marking a virtual method with 'virtual' > > 2. Deprecate not marking a virtual method with 'virtual' > > 3. Make it an error to not mark virtual methods with 'virtual' > > > > At this point, all methods are marked with either 'virtual', 'final', > > 'abstract', or 'override' or are implicitly final. (eg template methods, > > constructors) > > > > 4. Do not require 'final' to mark a function as final. (optional) > > Since I already started writing this, I may as well paste it here: > http://wiki.dlang.org/DIP51 > It can be updated if details emerge. I updated it. The warning goes on the introducing method, not on the overriding one. This forces all methods to be correctly annotated, even if there are no derived classes.

(In reply to comment #2) > (In reply to comment #1) > > (In reply to comment #0) > > > Thread with discussion and Walter-approval: > > > > > > http://forum.dlang.org/thread/[email protected]?page=28#post-koqkhc:244nn:241:40digitalmars.com > > > > > > 1. Add warning for not marking a virtual method with 'virtual' > > > 2. Deprecate not marking a virtual method with 'virtual' > > > 3. Make it an error to not mark virtual methods with 'virtual' > > > > > > At this point, all methods are marked with either 'virtual', 'final', > > > 'abstract', or 'override' or are implicitly final. (eg template methods, > > > constructors) > > > > > > 4. Do not require 'final' to mark a function as final. (optional) > > > > Since I already started writing this, I may as well paste it here: > > http://wiki.dlang.org/DIP51 > > It can be updated if details emerge. > > I updated it. The warning goes on the introducing method, not on the > overriding one. This forces all methods to be correctly annotated, even if > there are no derived classes. You mean to disallow an implicit state? So it's not final-by-default, rather, it MUST be explicitly specified?

(In reply to comment #3) > > You mean to disallow an implicit state? So it's not final-by-default, rather, > it MUST be explicitly specified? final-by-default comes last. The plan is to force the user to annotate everything, then relax the rules again. This way no functions move from virtual->non-virtual without user intervention.

(In reply to comment #4) > (In reply to comment #3) > > > > You mean to disallow an implicit state? So it's not final-by-default, rather, > > it MUST be explicitly specified? > > final-by-default comes last. The plan is to force the user to annotate > everything, then relax the rules again. This way no functions move from > virtual->non-virtual without user intervention. Hmmm, okay. I guess that's fair enough. It makes it explicit for a while then there's no ambiguity of intent.

*** Issue 7726 has been marked as a duplicate of this issue. ***

Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/b900262a9cbde7247a5eb0abc9de218500f7e229 Issue 11616 - Introduce virtual keyword Introduce the virtual keyword https://github.com/D-Programming-Language/dmd/commit/28acc4a364f751225b544b12c082dab037783d12 Merge pull request #2895 from yebblies/issue11616 Issue 11616 - Introduce virtual keyword

A possibly silly question, is this code OK (currently it compiles)? class Foo { virtual final void bar() {} } void main() {}

(In reply to comment #8) > A possibly silly question, is this code OK (currently it compiles)? > > > class Foo { > virtual final void bar() {} > } > void main() {} An oversight, it should give you an error the same as `@safe @system void fun();` does. Please file a bug for it.

(In reply to comment #9) > An oversight, it should give you an error the same as `@safe @system void > fun();` does. Please file a bug for it. Yet it seems C++11 allows it: http://en.wikipedia.org/wiki/C%2B%2B0x#Explicit_overrides_and_final http://stackoverflow.com/questions/6788338/final-virtual-functions-in-c0x http://stackoverflow.com/questions/11704406/whats-the-point-of-a-final-virtual-function

(In reply to comment #10) > (In reply to comment #9) > > > An oversight, it should give you an error the same as `@safe @system void > > fun();` does. Please file a bug for it. > > Yet it seems C++11 allows it: > > http://en.wikipedia.org/wiki/C%2B%2B0x#Explicit_overrides_and_final > > http://stackoverflow.com/questions/6788338/final-virtual-functions-in-c0x > > http://stackoverflow.com/questions/11704406/whats-the-point-of-a-final-virtual-function Interesting... Still, because we have attribute scopes/labels that would be harmful in D. eg virtual: final: void fun(); Here fun should be final, not both virtual and final. This should behave the same way as "virtual final".

? I think the decision on this was pretty clear.

Guess we'll need a postdenied keyword now too. :P

I'll never accept it! ;)

As I understand, in C++ `virtual final` works like `final override` would work in D.

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18722 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB