Difference between revisions of "DIP51"

From D Wiki
Jump to: navigation, search
(Created page with "{| class="wikitable" !Title: !'''not-virtual-by-default''' |- |DIP: |51 |- |Version: |1 |- |Status: |Draft |- |Created: |2013-11-27 |- |Last Modified: |2013-11-27 |- |Author: ...")
 
(Updated)
Line 29: Line 29:
 
In support of this change, introduction of the 'virtual' keyword will be required, and a deprecation process similar to the introduction of override will be followed.
 
In support of this change, introduction of the 'virtual' keyword will be required, and a deprecation process similar to the introduction of override will be followed.
 
'final' will be preserved, and remain useful to effectively 'seal' a hierarchy, in the same way as is useful in Java, C++, and C# (via 'sealed').
 
'final' will be preserved, and remain useful to effectively 'seal' a hierarchy, in the same way as is useful in Java, C++, and C# (via 'sealed').
 +
 +
== Process ==
 +
 +
Introduction of virtual would be added in steps:
 +
# The virtual keyword is introduced; it becomes a warning to 'override' a base function not marked virtual.
 +
# deprecate overriding base functions not marked virtual.
 +
# It becomes a compile error; virtual is enforced.
 +
 +
At this point, all methods are marked with either 'virtual', 'override', 'final', 'abstract', or are implicitly final.
  
 
== Example ==
 
== Example ==
Line 35: Line 44:
 
class Base
 
class Base
 
{
 
{
   virtual f();
+
  f();
 +
   virtual g();
 +
  final h();
 
}
 
}
  
 
class Derived : Base
 
class Derived : Base
 
{
 
{
   override f();
+
   override f(); // <- warning->deprecated->error, f() is implicitly final
 +
  override g(); // <- this is the proper hierarchy
 +
  override h(); // <- error, h() is explicitly final
 
}
 
}
 
</syntaxhighlight>
 
</syntaxhighlight>
  
...WIP
+
== Interfaces ==
 +
 
 +
For brevity, it is safe to assume all methods of an interface are implicitly virtual.
 +
 
 +
<syntaxhighlight lang="d">
 +
interface Interface
 +
{
 +
  f(); // <- implicitly virtual
 +
}
 +
 
 +
class Class : Interface
 +
{
 +
  override f(); // <- f() is declared in an interface, which is implicitly virtual
 +
}
 +
</syntaxhighlight>

Revision as of 13:16, 27 November 2013

Title: not-virtual-by-default
DIP: 51
Version: 1
Status: Draft
Created: 2013-11-27
Last Modified: 2013-11-27
Author: Manu Evans

Abstract

Virtual calls are inefficient, and through extensive discussion, it has been shown that it is impossible for an optimiser to safely finalise virtuals in any useful capacity in a non-JIT/VM environment. This DIP proposes that class methods need to be non-virtual by default, or D classes will always yield inferior performance characteristics to other native languages.

In support of this change, introduction of the 'virtual' keyword will be required, and a deprecation process similar to the introduction of override will be followed. 'final' will be preserved, and remain useful to effectively 'seal' a hierarchy, in the same way as is useful in Java, C++, and C# (via 'sealed').

Process

Introduction of virtual would be added in steps:

  1. The virtual keyword is introduced; it becomes a warning to 'override' a base function not marked virtual.
  2. deprecate overriding base functions not marked virtual.
  3. It becomes a compile error; virtual is enforced.

At this point, all methods are marked with either 'virtual', 'override', 'final', 'abstract', or are implicitly final.

Example

class Base
{
  f();
  virtual g();
  final h();
}

class Derived : Base
{
  override f(); // <- warning->deprecated->error, f() is implicitly final
  override g(); // <- this is the proper hierarchy
  override h(); // <- error, h() is explicitly final
}

Interfaces

For brevity, it is safe to assume all methods of an interface are implicitly virtual.

interface Interface
{
  f(); // <- implicitly virtual
}

class Class : Interface
{
  override f(); // <- f() is declared in an interface, which is implicitly virtual
}