www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Future of export

reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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-26bf588c0174e6cd
fe3d4af615bebdaR120 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?
Aug 22 2017
parent reply solidstate1991 <laszloszeremi outlook.com> writes:
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-26bf588c0174e6cd
fe3d4af615bebdaR120 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.
Aug 23 2017
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Aug 23 2017
parent Jerry <hurricane hereiam.com> writes:
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
Aug 26 2017