From D Wiki
Revision as of 09:22, 1 September 2013 by Ingrater (talk | contribs)
Jump to: navigation, search
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


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.


  • 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.


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()

module executable;
import sharedLib;

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

  public ovveride void func()

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.

Implicitly exporting compiler internal symbols of a module

Currently compiler internal symbols of modules are not exported at all. This leads to liner errors when linking against shared libraries on windows. By marking compiler internal symbols as 'export' as soon as there is a single exported symbol in the module will fix this problem.

export attribute inferrence

Currently export has to be specified in a lot of places to export all neccessary functions and data symbols. Export should be transitive in such a sense that it only needs to be specified once in a module to export all of its functions / data members including classes and their members / data symbols. Consider the following example:

module sharedLib:


__gshared int g_Var; // should be exported

void globalFunc() { ... } // should be exported

class A // compiler internal members should be exported
    int m_a;

    static int s_b; // should not be exported

    void internalFunc() { ... } // should not be exported

    void interalFunc2() { ... } // should be exported

    class Inner // compiler internal members should be exported
       static s_inner; // should be exported

       void innerMethod() { ... } // should be exported

    void method() { ... } // should be exported

private class C // should not be exported
   public void method() { ... } // should not be exported

Access TLS variables

Currently it is not possible to acces TLS variables across shared library boundaries. This should be implemented. See implementation details.

Change symbol visibility on *nix systems

When building shared libraries on *nix systems all symbols are visible by default. This can lead to long loading time of shared libraries if they contain a large number of symbols. Also everything visible by deafult makes it hard to commit to a certain stable interface, as one has no control over the visible symbols.

Implementation Details




This document has been placed in the Public Domain.