Difference between revisions of "DIP51"

From D Wiki
Jump to: navigation, search
(Updated)
 
(2 intermediate revisions by one other user not shown)
Line 33: Line 33:
  
 
Introduction of virtual would be added in steps:
 
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.
+
# The virtual keyword is introduced; it becomes a warning to declare a virtual base function not marked virtual.
# deprecate overriding base functions not marked virtual.
+
# deprecate declaring virtual functions not marked virtual.
 
# It becomes a compile error; virtual is enforced.
 
# It becomes a compile error; virtual is enforced.
  
Line 44: Line 44:
 
class Base
 
class Base
 
{
 
{
   f();
+
   f(); // <- warning->deprecated->error, f() is implicitly final
 
   virtual g();
 
   virtual g();
 
   final h();
 
   final h();
Line 51: Line 51:
 
class Derived : Base
 
class Derived : Base
 
{
 
{
   override f(); // <- warning->deprecated->error, f() is implicitly final
+
   override f()
   override g(); // <- this is the proper hierarchy
+
   override g(); // <- valid
 
   override h(); // <- error, h() is explicitly final
 
   override h(); // <- error, h() is explicitly final
 
}
 
}
Line 72: Line 72:
 
}
 
}
 
</syntaxhighlight>
 
</syntaxhighlight>
 +
 +
[[Category: DIP]]

Latest revision as of 19:52, 1 September 2015

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 declare a virtual base function not marked virtual.
  2. deprecate declaring virtual 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();  // <- warning->deprecated->error, f() is implicitly final
  virtual g();
  final h();
}

class Derived : Base
{
  override f()
  override g(); // <- valid
  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
}