I have as part of DIP 1012

```
enum SymbolExport
{
    neither,
    dynamicImport,
    dynamicExport
}

alias dynamicImport = SymbolExport .dynamicImport;
alias dynamicExport = SymbolExport .dynamicExport;
```

to replace the `export` storage visibility, So that one can do

```
version(MyLib_Build)
    enum MyLibExport = dynamicExport;
else
    enum MyLibExport = dynamicImport;

// Exported when building the shared object,
//imported when linking against the shared object.
@MyLibExport void foo(int x) { ... }
```

However Martin said in https://github.com/dlang/DIPs/pull/89/files#diff-26bf588c0174e6cd0fe3d4af615bebdaR120 that "That's not what is planned for export"

Last I heard (from Benjamins Thaut's DConf 2016 talk) was that nobody was using export because there was no corresponding import and no way to switch between them. Benjamin suggested that making it an attribute would fix that, hence it is part of DIP 1012.

What is planned for export?

On Wednesday, 23 August 2017 at 03:19:55 UTC, Nicholas Wilson wrote:
> I have as part of DIP 1012
>
> ```
> enum SymbolExport
> {
>     neither,
>     dynamicImport,
>     dynamicExport
> }
>
> alias dynamicImport = SymbolExport .dynamicImport;
> alias dynamicExport = SymbolExport .dynamicExport;
> ```
>
> to replace the `export` storage visibility, So that one can do
>
> ```
> version(MyLib_Build)
>     enum MyLibExport = dynamicExport;
> else
>     enum MyLibExport = dynamicImport;
>
> // Exported when building the shared object,
> //imported when linking against the shared object.
> @MyLibExport void foo(int x) { ... }
> ```
>
> However Martin said in https://github.com/dlang/DIPs/pull/89/files#diff-26bf588c0174e6cd0fe3d4af615bebdaR120 that "That's not what is planned for export"
>
> Last I heard (from Benjamins Thaut's DConf 2016 talk) was that nobody was using export because there was no corresponding import and no way to switch between them. Benjamin suggested that making it an attribute would fix that, hence it is part of DIP 1012.
>
> What is planned for export?

There's already a DIP on the subject (https://github.com/dlang/DIPs/blob/master/DIPs/archive/DIP45.md), but it's pretty much abandoned. I however would like to see it becoming a subject of discussion. DIP45 should be done as soon as possible, so the D will be able to have a much better DLL support, which in turn will help both our development, both the adoption of the language.

On Thursday, 24 August 2017 at 00:31:26 UTC, solidstate1991 wrote:
> There's already a DIP on the subject (https://github.com/dlang/DIPs/blob/master/DIPs/archive/DIP45.md), but it's pretty much abandoned. I however would like to see it becoming a subject of discussion. DIP45 should be done as soon as possible, so the D will be able to have a much better DLL support, which in turn will help both our development, both the adoption of the language.

Thanks. The interesting bit of that DIP w.r.t DIP1012 is

> A single meaning of export
>
> The classical solution to handle dllexport/dllimport attributes on Windows is to define macro that depending on the current build setting expands to __declspec(dllexport) or to __declspec(dllimport). This complicates the build setup and means that object files for a static library can't be mixed well with object files for a DLL. Instead we propose that exported data definitions are accompanied with an _imp_ pointer and always accessed through them. See the implementation detail section for how this will work for data symbols and function symbols. That way a compiled object file can be used for a DLL or a static library. And vice versa an object file can be linked against an import library or a static library.

I can't comment on the build system complexity that DIP1012 would add but It would allow us to do the C/C++ solution of export management.

I'll have a proper look over DIP45's review thread and put a summary here and see if we can get some discussion on it.

Export was being implemented as an attribute last I saw of it, by the guy that made that DIP. Looks like he last worked on it some time in July.

https://github.com/Ingrater/dmd/commits/DllSupportD2