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 : « Export means that any code outside the
executable can access the member. Export is
analogous to exporting definitions 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.
