Future of export

[Nicholas Wilson via Digitalmars-d]

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.