On Monday, 16 February 2015 at 21:41:00 UTC, Walter Bright wrote:
> On 2/16/2015 12:19 PM, Jacob Carlborg wrote:
>> Most likely due to that the support for dynamic libraries is fairly new only
>> works on Linux (?).
>
> Part of the test suite creates a DLL using D for Windows.

Martin recently added shared library support for FreeBSD also:

https://github.com/D-Programming-Language/druntime/pull/1068

So i looked at the Dll Test within the dmd test framework and when I make export an attribute, like I suggested, this perticular test will compile & run without any code changes. This is another reason why I suspect that making export an attribute will only break very little if any code at all.

Am 16.02.2015 um 09:08 schrieb Walter Bright:
>
> At this point I suggest simply making those private helper functions
> public and export them. It gets your project moving without waiting for
> language changes (and this is a breaking change).
>

I have to big fears with doing this

1) I finish everything up any finally do the pull request. Then the reviewers will realize that using export in all required places will completely undermine D's module level protection system and reject the PR. Then all my work is in vain.

2) Even if 1 does not happen, that means from now on the broken export will be used in _actual_ code. Because it kind of works. Going forward this would mean that changing export into an attribute will break actual production code. So in my opinion we have to implement Dll Support on windows and fix export simulatiously, otherwise fixing export will lead to big breaking changes instead of a few small ones.

Kind Regards
Benjamin Thaut

Hi,

I also want to say a big thank you to all of you involved
in this topic and especially to Benjamin.

Proper DLL handling in D I would really appreciate.
I think this topic is the break through.

Kind regards
André

On Tuesday, 17 February 2015 at 18:03:06 UTC, Benjamin Thaut wrote:
> So i looked at the Dll Test within the dmd test framework and when I make export an attribute, like I suggested, this perticular test will compile & run without any code changes. This is another reason why I suspect that making export an attribute will only break very little if any code at all.
>
> Am 16.02.2015 um 09:08 schrieb Walter Bright:
>>
>> At this point I suggest simply making those private helper functions
>> public and export them. It gets your project moving without waiting for
>> language changes (and this is a breaking change).
>>
>
> I have to big fears with doing this
>
> 1) I finish everything up any finally do the pull request. Then the reviewers will realize that using export in all required places will completely undermine D's module level protection system and reject the PR. Then all my work is in vain.
>
> 2) Even if 1 does not happen, that means from now on the broken export will be used in _actual_ code. Because it kind of works. Going forward this would mean that changing export into an attribute will break actual production code. So in my opinion we have to implement Dll Support on windows and fix export simulatiously, otherwise fixing export will lead to big breaking changes instead of a few small ones.
>
> Kind Regards
> Benjamin Thaut

On Monday, 16 February 2015 at 20:19:27 UTC, Jacob Carlborg wrote:
> On 2015-02-16 10:40, Benjamin Thaut wrote:
>
>> This is in fact not a breaking change because export is broken anyway.
>> Due to bug 922 export can't be used in cross platform libraries. I
>> haven't seen a single library on dub that uses export (most likely for
>> exactly that reason).
>
> Most likely due to that the support for dynamic libraries is fairly new only works on Linux (?).

And the way it currently works on Linux `export` is completely ignored at all - hard to break something that has never worked.