Difference between revisions of "DIP74"

From D Wiki
Jump to: navigation, search
Line 49: Line 49:
  
 
<syntaxhighlight lang=D>
 
<syntaxhighlight lang=D>
class Widget1 {
+
@safe class Widget1 {
 
     private int data;
 
     private int data;
 
     ref int getData() { return data; } // fine
 
     ref int getData() { return data; } // fine
Line 55: Line 55:
 
}
 
}
  
class Widget2 {
+
@safe class Widget2 {
 
     private int data;
 
     private int data;
 
     ref int getData1() { return data; } // ERROR
 
     ref int getData1() { return data; } // ERROR
Line 65: Line 65:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
== Defining a reference counted class ==
+
This is because it is safe for a garbage collected object to escape references to its internal state. The same is not allowed for reference counted objects because they are expected to be deallocated in a deterministic manner (same as e.g. <tt>struct</tt> objects on the stack).
 +
 
 +
== Defining a reference counted object with deallocation ==
  
 
TODO
 
TODO

Revision as of 03:14, 26 February 2015

Title: Safe Reference Counted Class Objects
DIP: 74
Version: 1
Status: Concept
Created: 2015-02-23
Last Modified: 2015-02-26
Author: Walter Bright and Andrei Alexandrescu

Abstract

This DIP proposes @safe reference counted class objects for D (including exceptions).

Description

DIP25 allows defining struct types that own data and expose references to it, @safely, whilst controlling lifetime of that data. This proposal allows defining class objects that are safe yet use deterministic destruction for themselves and resources they own.

The compiler detects automatically and treats specially all classes and interfaces that define the following two methods:

class Widget {
    ulong AddRef();
    ulong Release();
    ...
}

The methods may or may not be final or inherited. Any attributes are allowed on these methods. They must be public. If these two methods are accessible, the compiler categorizes this class type as a reference counted class and treats it as follows:

  • Whenever a new reference to an object is created, compiler inserts an implicit call to AddRef. Call is inserted only if the reference is not null. There is no call inserted for the first reference created via a constructor.
  • Whenever a reference to an object goes out of scope, compiler inserts an implicit call to Release. Call is inserted only if the reference is not null.
  • Implicit conversion to supertypes (class or interface) is allowed ONLY if the supertype also is a reference counted type. It follows that reference counted types cannot be converted to Object (unless Object itself defines the two methods).
  • Typechecking methods of reference counted types is done the same as for structs. This is important because it limits what reference counted types. Consider:
@safe class Widget1 {
    private int data;
    ref int getData() { return data; } // fine
    ...
}

@safe class Widget2 {
    private int data;
    ref int getData1() { return data; } // ERROR
    ref int getData2() return { return data; } // fine
    ulong AddRef();
    ulong Release();
    ...
}

This is because it is safe for a garbage collected object to escape references to its internal state. The same is not allowed for reference counted objects because they are expected to be deallocated in a deterministic manner (same as e.g. struct objects on the stack).

Defining a reference counted object with deallocation

TODO

class Widget {
   ulong AddRef();
   ulong Release();
   ...
}

Copyright

This document has been placed in the Public Domain.