Export ?

[Maxim Fomin]

On Tuesday, 10 April 2012 at 17:34:25 UTC, deadalnix wrote:
> On this newsgroup with Jonathan M Davis, we started discussing 
> export. As it was off topic, and as it was interesting, I wish 
> to bring it here.
>
> As most of you know, all symbol on posix systems are export, 
> but not on windows. As D have an export keyword, the question 
> is what to do with it.
>
> The need for change in the UNIX world of this behavior exists, 
> and some move has been made in direction of explicitly hiding 
> symbols ( see http://gcc.gnu.org/wiki/Visibility ).
>
> For consistency across systems, I suggest that, unless marked 
> as exported, symbols are hidden by default. This have other 
> advantages as shown in the linked page about gcc. For D, it 
> also mean that the linker will have all information to finalize 
> all methods that are not marked as export, and I think this is 
> something we want to mitigate the cost of all methods virtual 
> by default.
>
> The site says : « Ex­port means that any code out­side the 
> ex­e­cutable can ac­cess the mem­ber. Ex­port is 
> anal­o­gous to ex­port­ing de­f­i­n­i­tions from a 
> DLL. » so, clearly it is not saying anything about posix 
> systems (you'll not find many DLL on those) and not what D 
> compiler does.
>
> It means that export comes as an extra qualifier, and not as an 
> alternative to public/private/protected/package . You can be 
> both export AND public/private/protected/package .
>
> This already have been discussed here, but no conclusion has 
> been made.

I found current export keyword "imaginary" because D treats each 
module as implementation and you have have no ability to divide 
declaration from implementation except pure C functions, which 
eliminates all D features. Each time when you import module it is 
pulled in a one executable. You can mark anything in a source 
code (which supposed to be part of the library) with export 
keyword but you either 1) pull it in the same executable with 
application and you don't care about whether it is exported or 
not or 2) compile "library" separately but you still have to 
import it (all source code, including implementation) when 
compiling "application" (you cannot import any declaration like 
in C/C++) and again you are indifferent about export keyword. So, 
I found export keyword as a pure comment and as much useful like 
"doesn't_launch_missiles" qualifier is.

When I faced the problem in D that if I want to interface with 
shared library I only can do this through basic C-like functions 
(http://dlang.org/dll.html#Dcode), I feel like I am offered an 
attractive bag with broken handle.