The logic behind the export keyword seems to be flawed. As explained in this ticket:

http://d.puremagic.com/issues/show_bug.cgi?id=9816

For declarations export means __declspec(dllimport) and for definitions __declspec(dllexport).

export void foo();   // this treated as import
export void foo() {} // this treated as export

For global variables to be an export you need an initializer.

export __gshared int bar;     // this treated as import
export __gshared int bar = 0; // this treated as export

This makes using the export keyword very cumbersome as you always have to pay attention to initialize variables so they actually get treated as export and also you most likely will always need a .d file and a .di file for the same module to make it work. Can't we think of a different logic for the export keyword so you only have to write the module once and it works in both cases?

I could also only find a single line in the language documentation describing export which doesn't really help understanding it:

"Export means that any code outside the executable can access the member. Export is analogous to exporting definitions from a DLL. "

So whats a "member"? A class, a function, a member variable? What about global variables? Vtables? TypeInfo objects? RTInfo!T instances? From my experiences the only thing that does actually work is exporting functions, everything else is broken (see the bug ticket mentioned above).

Now that we have shared library support on linux platforms it would be nice if we could get it on Windows too. I'm currently looking into exporting variables from dlls but the lack of documentation on the topic makes it hard. Any insights, links, references to books or other materials are welcome.

Kind Regards
Benjamin Thaut

On 8/25/13, Benjamin Thaut <code@benjamin-thaut.de> wrote:
> This makes using the export keyword very cumbersome as you always have to pay attention to initialize variables so they actually get treated as export.

Yeah I dislike this behavior as well, I think it might have been
carried over from C/C++ (?).

Also look at the confusing extern keyword semantics: http://dlang.org/declaration.html#extern

On 2013-08-25 15:18, Andrej Mitrovic wrote:

> Also look at the confusing extern keyword semantics:
> http://dlang.org/declaration.html#extern

What's confusing about the extern keyword?

-- 
/Jacob Carlborg

On 2013-08-25 14:17, Benjamin Thaut wrote:

> export __gshared int bar;     // this treated as import

I would have guessed that required extern as well to be import.

-- 
/Jacob Carlborg

Am 25.08.2013 15:51, schrieb Jacob Carlborg:
> On 2013-08-25 14:17, Benjamin Thaut wrote:
>
>> export __gshared int bar;     // this treated as import
>
> I would have guessed that required extern as well to be import.
>

But as D does not have a Preprocessor and version statements can not be used to replace the usual API macros used in C/C++ we need export to work in a way so that it means both import and export at the same time.

-- 
Kind Regards
Benjamin Thaut

On 8/25/13, Jacob Carlborg <doob@me.com> wrote:
>> Also look at the confusing extern keyword semantics: http://dlang.org/declaration.html#extern
>
> What's confusing about the extern keyword?

`extern` => storage class, `extern(NAME)` => linkage attribute. Using the same keyword for two things is confusing.