Difference between revisions of "DIP45"

From D Wiki
Jump to: navigation, search
(Description)
(Rationale)
Line 41: Line 41:
 
==Rationale==
 
==Rationale==
  
Work in progress
+
===Turning export into an attribute===
 +
 
 +
Currently the export protection level is the highest level of visibility. This however does not allow exporting protected members. Exported protected members is neccessary sometimes though.
 +
Consider the following example.
 +
 
 +
<syntaxhighlight lang=D>
 +
module sharedLib;
 +
 
 +
class Base
 +
{
 +
  protected final void DoSomething() { ... }
 +
 
 +
  public void func()
 +
  {
 +
    DoSomething();
 +
  }
 +
}
 +
</syntaxhighlight>
 +
 
 +
 
 +
<syntaxhighlight lang=D>
 +
module executable;
 +
import sharedLib;
 +
 
 +
class Derived
 +
{
 +
  protected final void DoSomethingAdditional() { ... }
 +
 
 +
  public ovveride void func()
 +
  {
 +
    DoSomething();
 +
    DoSomethingAdditional();
 +
  }
 +
}
 +
</syntaxhighlight>
 +
 
 +
In the above example 'DoSomething' should only be visible to derived classes but should still be exported from a shared library. This does not work with the current implementation of 'export'. Turning 'export' into an attribute will make this work.
  
 
==Implementation Details==
 
==Implementation Details==

Revision as of 09:07, 1 September 2013

Title: making export an attribute
DIP: 45
Version: 1
Status: Draft
Created: 2013-08-27
Last Modified: 2013-08-30
Author: Benjamin Thaut
Links: http://forum.dlang.org/post/5112D61B.5010905@digitalmars.com

http://forum.dlang.org/post/kvhu2c$2ikq$1@digitalmars.com http://d.puremagic.com/issues/show_bug.cgi?id=9816

Abstract

Export and its behavior needs to be changed in serveral ways to make it work on Windows and allow better code generation for other plattforms. The Rationale section explains the problem and shows how this DIP solves it.

Description

  • The 'export' protection level should be turned into a 'export' attribute.
  • If a module contains a single symbol annotated with the 'export' attribute all compiler internal symbols of this module should recieve the 'export' attribute too (e.g. module info).
  • If a class is annotated with the 'export' attribute, all of its public and protected functions and members will automatically recieve the 'export' attribute. Also all its hidden compiler specific symbols will recieve the 'export' attribute.
  • It should be possible to access TLS variables across DLL / shared library boundaries.
  • On *nix systems default symbol visibility is changed to hidden, and only with export marked symbols are visible.

Rationale

Turning export into an attribute

Currently the export protection level is the highest level of visibility. This however does not allow exporting protected members. Exported protected members is neccessary sometimes though. Consider the following example.

module sharedLib;

class Base
{
  protected final void DoSomething() { ... }

  public void func()
  {
    DoSomething();
  }
}


module executable;
import sharedLib;

class Derived
{
  protected final void DoSomethingAdditional() { ... }

  public ovveride void func()
  {
    DoSomething();
    DoSomethingAdditional();
  }
}

In the above example 'DoSomething' should only be visible to derived classes but should still be exported from a shared library. This does not work with the current implementation of 'export'. Turning 'export' into an attribute will make this work.

Implementation Details

Work in progress

Copyright

This document has been placed in the Public Domain.