On Wednesday, 28 January 2015 at 13:48:45 UTC, Dicebot wrote:
> Isn't that what your first proposed solution is about? That was my understanding and I liked that understanding :) To be 100% clear :
>
> export void foo(T : int)(T x)
> {
>     bar(x);
> }
>
> private void bar(int x) { }
>
> I'd expect `bar` to be exported into resulting binary so that it can be linked against by any users of `foo` but for any attempt to call `bar` directly from D code to fail because of protection violation. If someone wants to circumvent protection by forging mangling - shooting own feet is allowed.

So you'd want bar to be duplicated on both sides ? This is gonna cause problems with di files.

Am 31.01.2015 um 23:42 schrieb deadalnix:
> On Wednesday, 28 January 2015 at 13:48:45 UTC, Dicebot wrote:
>> Isn't that what your first proposed solution is about? That was my
>> understanding and I liked that understanding :) To be 100% clear :
>>
>> export void foo(T : int)(T x)
>> {
>>     bar(x);
>> }
>>
>> private void bar(int x) { }
>>
>> I'd expect `bar` to be exported into resulting binary so that it can
>> be linked against by any users of `foo` but for any attempt to call
>> `bar` directly from D code to fail because of protection violation. If
>> someone wants to circumvent protection by forging mangling - shooting
>> own feet is allowed.
>
> So you'd want bar to be duplicated on both sides ? This is gonna cause
> problems with di files.

No. He wants the compiler to automatically detect that the template foo might call bar. As a result the compiler should export bar when compiling the shared library so that any user of foo does not run into a "unresolved symbol reference" linker error. Bar would still only exist once: within the shared library.

On Sunday, 1 February 2015 at 09:24:46 UTC, Benjamin Thaut wrote:
>> So you'd want bar to be duplicated on both sides ? This is gonna cause
>> problems with di files.
>
> No. He wants the compiler to automatically detect that the template foo might call bar. As a result the compiler should export bar when compiling the shared library so that any user of foo does not run into a "unresolved symbol reference" linker error. Bar would still only exist once: within the shared library.

Correct. Sadly it won't work that way as I was already pointed at.
Otherwise it is perfect solution :P

On 1/31/2015 11:52 AM, Benjamin Thaut wrote:
> @Walter:
> Making export a attribute seems to be the preferred choice in this discussion.
> Additionaly this was the result of the last discussion around export, a year
> ago, although for different reasons. The last Discussion resulted in DIP 45
> which also proposes making export an attribute. Before I start with the
> implementation, would you be ok with making export an attribute or would you
> veto it?

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).

On Monday, 16 February 2015 at 08:08:17 UTC, Walter Bright wrote:
> On 1/31/2015 11:52 AM, Benjamin Thaut wrote:
>> @Walter:
>> Making export a attribute seems to be the preferred choice in this discussion.
>> Additionaly this was the result of the last discussion around export, a year
>> ago, although for different reasons. The last Discussion resulted in DIP 45
>> which also proposes making export an attribute. Before I start with the
>> implementation, would you be ok with making export an attribute or would you
>> veto it?
>
> 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).

This is not about some private project but about fixing language itself.

On Monday, 16 February 2015 at 08:08:17 UTC, Walter Bright wrote:
>
> 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).

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).
Also export on windows is broken as well, see Bug 9816.

So making export an attribute would most likely not break anything because it already is broken and wouldn't work if you tried to use it.

On 2/16/2015 1:40 AM, Benjamin Thaut wrote:
> On Monday, 16 February 2015 at 08:08:17 UTC, Walter Bright wrote:
>>
>> 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).
>
> 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).
> Also export on windows is broken as well, see Bug 9816.
>
> So making export an attribute would most likely not break anything because it
> already is broken and wouldn't work if you tried to use it.

From https://issues.dlang.org/show_bug.cgi?id=9816:

----------
Here is a list of all things wrong with export:

32 & 64 bit issues:
1) Exporting a global variable leads to a linker error
2) Exporting thread local variables should be an error (at least it is in c++)
3) The module info should be exported as soon the module has any exported
symbols
4) __gshared members of a class are not exported
5) The TypeInfo Object of the TestClass is not exported
6) The TypeInfo Object of TestStruct is not exported
---------

None of these are addressed by making export an attribute.

On Monday, 16 February 2015 at 09:59:07 UTC, Walter Bright wrote:
>
> ----------
> Here is a list of all things wrong with export:
>
> 32 & 64 bit issues:
> 1) Exporting a global variable leads to a linker error
> 2) Exporting thread local variables should be an error (at least it is in c++)
> 3) The module info should be exported as soon the module has any exported
> symbols
> 4) __gshared members of a class are not exported
> 5) The TypeInfo Object of the TestClass is not exported
> 6) The TypeInfo Object of TestStruct is not exported
> ---------
>
> None of these are addressed by making export an attribute.

I never said that. I said that making export an attribute is _not_ an breaking change because it is already broken up to a point where it currently can't be used anyway (especially because of 922). My current implementation fixes both 922 and 9816 but would greatly benefit from making export an attribute because otherwise D's entire protection system would be undermined like described multiple times throughout this thread.

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 (?).

-- 
/Jacob Carlborg

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.