www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Export ?

reply deadalnix <deadalnix gmail.com> writes:
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.
Apr 10 2012
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, April 10, 2012 19:36:06 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 ).


As I said in the other thread, I _hate_ export. It's one of Windows largest 
misfeatures IMHO. It drives me nuts when I have to deal with it in C++. The 
fact that Linux exports everything is _fantastic_. It's so much easier to deal 
with. I'd _hate_ to see Linux or anything we do move in the direction of what 
Windows has done.

- Jonathan M Davis
Apr 10 2012
next sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Tuesday, 10 April 2012 at 17:44:54 UTC, Jonathan M Davis wrote:

 As I said in the other thread, I _hate_ export. It's one of 
 Windows largest
 misfeatures IMHO. It drives me nuts when I have to deal with it 
 in C++. The
 fact that Linux exports everything is _fantastic_. It's so much 
 easier to deal
 with. I'd _hate_ to see Linux or anything we do move in the 
 direction of what
 Windows has done.

 - Jonathan M Davis


Agreed. Ideally, there would be a compiler flag to export all 
public symbols by default. Public is there for a reason, public 
is default for a reason. Now forcing a bunch of clutter just to 
add expor to everything, would defeat the purpose and is the 
single largest reason I don't use DLLs.
Apr 10 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 10/04/2012 20:00, Kapps a écrit :

 On Tuesday, 10 April 2012 at 17:44:54 UTC, Jonathan M Davis wrote:

 As I said in the other thread, I _hate_ export. It's one of Windows
 largest
 misfeatures IMHO. It drives me nuts when I have to deal with it in
 C++. The
 fact that Linux exports everything is _fantastic_. It's so much easier
 to deal
 with. I'd _hate_ to see Linux or anything we do move in the direction
 of what
 Windows has done.

 - Jonathan M Davis


 Agreed. Ideally, there would be a compiler flag to export all public
 symbols by default. Public is there for a reason, public is default for
 a reason. Now forcing a bunch of clutter just to add expor to
 everything, would defeat the purpose and is the single largest reason I
 don't use DLLs.


Note that this is easy to perform without compiler flag, with an « export: »
Apr 11 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
Windows is not alone in this regard. AIX uses a similar behaviour

http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/topic/com.ibm.vacpp7a.doc/proguide/ref/compile_library.htm#compile_library

Remember not all UNIXes are made alike. :)

--
Paulo



On Tuesday, 10 April 2012 at 17:44:54 UTC, Jonathan M Davis wrote:

 On Tuesday, April 10, 2012 19:36:06 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 ).


 As I said in the other thread, I _hate_ export. It's one of 
 Windows largest
 misfeatures IMHO. It drives me nuts when I have to deal with it 
 in C++. The
 fact that Linux exports everything is _fantastic_. It's so much 
 easier to deal
 with. I'd _hate_ to see Linux or anything we do move in the 
 direction of what
 Windows has done.

 - Jonathan M Davis
Apr 10 2012
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 10/04/2012 19:44, Jonathan M Davis a écrit :

 On Tuesday, April 10, 2012 19:36:06 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 ).


 As I said in the other thread, I _hate_ export. It's one of Windows largest
 misfeatures IMHO. It drives me nuts when I have to deal with it in C++. The
 fact that Linux exports everything is _fantastic_. It's so much easier to deal
 with. I'd _hate_ to see Linux or anything we do move in the direction of what
 Windows has done.

 - Jonathan M Davis


It isn't a misfeature. The link explain why it is interesting :
  - It improves load time of DSO.
  - Allow more optimizations.
  - Reduce DSO size by 5% to 20% for C++. Considering how long mangling 
are in D, probably more for us.
  - Reduce name collision (this one poorly apply to D, because the 
module system handle that quite nicely).

Additionally, it allow automatic finalization for non exported methods in D.

The drawback is having to explicitely export. I think it worth it, 
especially considering « export: » is an available solution. A compiler 
switch is also an option.

BTW, Linux is moving in that direction, for the advantages given above. 
Some other posix systems also does that already.
Apr 11 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, April 11, 2012 11:56:00 deadalnix wrote:

 Le 10/04/2012 19:44, Jonathan M Davis a =C3=A9crit :

 On Tuesday, April 10, 2012 19:36:06 deadalnix wrote:

 On this newsgroup with Jonathan M Davis, we started discussing exp=






ort.

 As it was off topic, and as it was interesting, I wish to bring it=






 here.

=20
 As most of you know, all symbol on posix systems are export, but n=






ot on

 windows. As D have an export keyword, the question is what to do w=






ith it.

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


=20
 As I said in the other thread, I _hate_ export. It's one of Windows=





 largest
 misfeatures IMHO. It drives me nuts when I have to deal with it in =




C++.

 The
 fact that Linux exports everything is _fantastic_. It's so much eas=




ier to

 deal with. I'd _hate_ to see Linux or anything we do move in the
 direction of what Windows has done.
=20
 - Jonathan M Davis


=20
 It isn't a misfeature. The link explain why it is interesting :
   - It improves load time of DSO.
   - Allow more optimizations.
   - Reduce DSO size by 5% to 20% for C++. Considering how long mangli=


ng

 are in D, probably more for us.
   - Reduce name collision (this one poorly apply to D, because the
 module system handle that quite nicely).
=20
 Additionally, it allow automatic finalization for non exported method=


s in D.

=20
 The drawback is having to explicitely export. I think it worth it,
 especially considering =C2=AB export: =C2=BB is an available solution=


. A compiler

 switch is also an option.
=20
 BTW, Linux is moving in that direction, for the advantages given abov=


e.

 Some other posix systems also does that already.


Honestly, I don't care what list of benefits you can come up with for h=
aving to=20
explicitly export symbols. I am sick and tired of having to deal with b=
uild=20
breakages due to unexported symbols in C++ on Windows. It is really, re=
allly,=20
really annoying. It's a usability nightmare as far as I'm concerned, an=
d I=20
don't want to see it spread any more than I want to see cancer spread.

As far as I'm concerned, Linux got this _right_ and Windows got it comp=
letely=20
wrong, and I do _not_ want to see export being used in D any further th=
an it=20
is. It's bad enough that the export keyword exists at all.

- Jonathan M Davis
Apr 11 2012
parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Wednesday, 11 April 2012 at 10:50:21 UTC, Jonathan M Davis 
wrote:

 As far as I'm concerned, Linux got this _right_ and Windows got 
 it completely
 wrong, and I do _not_ want to see export being used in D any 
 further than it
 is. It's bad enough that the export keyword exists at all.

 - Jonathan M Davis


I think the problem is deeper: C++, which you have mentioned, 
doesn't tell anything about libraries leaving programmer alone 
with unportable issues. So, the problem is inconsistent behavior 
across different implementations. It is better to say not that 
Linux got it right, but you were luckier with Linux, because its 
export policy was beneficial for you.

For example that bits Linux "everything is portable" policy, I 
had a cross platform project and thought that it would be safe to 
hide some internal functions but than i realized that it requires 
lots of unportable code.

If D would offer portable solution to this problem, it would be 
its yet another big win.
Apr 19 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 11 April 2012 13:50, Jonathan M Davis <jmdavisProg gmx.com> wrote:


 On Wednesday, April 11, 2012 11:56:00 deadalnix wrote:

 Le 10/04/2012 19:44, Jonathan M Davis a =C3=A9crit :

 On Tuesday, April 10, 2012 19:36:06 deadalnix wrote:

 On this newsgroup with Jonathan M Davis, we started discussing expor=








t.

 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 wit=








h

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


 As I said in the other thread, I _hate_ export. It's one of Windows
 largest
 misfeatures IMHO. It drives me nuts when I have to deal with it in C+=






+.

 The
 fact that Linux exports everything is _fantastic_. It's so much easie=






r

 to

 deal with. I'd _hate_ to see Linux or anything we do move in the
 direction of what Windows has done.

 - Jonathan M Davis


 It isn't a misfeature. The link explain why it is interesting :
   - It improves load time of DSO.
   - Allow more optimizations.
   - Reduce DSO size by 5% to 20% for C++. Considering how long mangling
 are in D, probably more for us.
   - Reduce name collision (this one poorly apply to D, because the
 module system handle that quite nicely).

 Additionally, it allow automatic finalization for non exported methods


 in D.

 The drawback is having to explicitely export. I think it worth it,
 especially considering =C2=AB export: =C2=BB is an available solution. =




A compiler

 switch is also an option.

 BTW, Linux is moving in that direction, for the advantages given above.
 Some other posix systems also does that already.


 Honestly, I don't care what list of benefits you can come up with for
 having to
 explicitly export symbols. I am sick and tired of having to deal with bui=


ld

 breakages due to unexported symbols in C++ on Windows. It is really,
 reallly,
 really annoying. It's a usability nightmare as far as I'm concerned, and =


I

 don't want to see it spread any more than I want to see cancer spread.

 As far as I'm concerned, Linux got this _right_ and Windows got it
 completely
 wrong, and I do _not_ want to see export being used in D any further than
 it
 is. It's bad enough that the export keyword exists at all.


Apply the same rules to Linux, and it'll never bother you again. It's the
only solution, you can't possibly influence Microsoft to apply the inverse.
As far as I'm concerned windows got it _right_ and linux got it... 'linux'.
I like DLL's being self contained modules with tightly controlled
interfaces. And deadalnix lists important points.
Apr 11 2012
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
And as I noted on my post, Windows is not alone in this regard.

Many other OS follow the same explicit export principle, AIX
being one of them.

Linux != UNIX

--
Paulo

On Wednesday, 11 April 2012 at 11:29:53 UTC, Manu wrote:

 On 11 April 2012 13:50, Jonathan M Davis <jmdavisProg gmx.com> 
 wrote:


 On Wednesday, April 11, 2012 11:56:00 deadalnix wrote:

 Le 10/04/2012 19:44, Jonathan M Davis a écrit :

 On Tuesday, April 10, 2012 19:36:06 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 ).


 As I said in the other thread, I _hate_ export. It's one 
 of Windows
 largest
 misfeatures IMHO. It drives me nuts when I have to deal 
 with it in C++.
 The
 fact that Linux exports everything is _fantastic_. It's so 
 much easier




 to

 deal with. I'd _hate_ to see Linux or anything we do move 
 in the
 direction of what Windows has done.

 - Jonathan M Davis


 It isn't a misfeature. The link explain why it is 
 interesting :
   - It improves load time of DSO.
   - Allow more optimizations.
   - Reduce DSO size by 5% to 20% for C++. Considering how 
 long mangling
 are in D, probably more for us.
   - Reduce name collision (this one poorly apply to D, 
 because the
 module system handle that quite nicely).

 Additionally, it allow automatic finalization for non 
 exported methods


 in D.

 The drawback is having to explicitely export. I think it 
 worth it,
 especially considering « export: » is an available 
 solution. A compiler
 switch is also an option.

 BTW, Linux is moving in that direction, for the advantages 
 given above.
 Some other posix systems also does that already.


 Honestly, I don't care what list of benefits you can come up 
 with for
 having to
 explicitly export symbols. I am sick and tired of having to 
 deal with build
 breakages due to unexported symbols in C++ on Windows. It is 
 really,
 reallly,
 really annoying. It's a usability nightmare as far as I'm 
 concerned, and I
 don't want to see it spread any more than I want to see cancer 
 spread.

 As far as I'm concerned, Linux got this _right_ and Windows 
 got it
 completely
 wrong, and I do _not_ want to see export being used in D any 
 further than
 it
 is. It's bad enough that the export keyword exists at all.


 Apply the same rules to Linux, and it'll never bother you 
 again. It's the
 only solution, you can't possibly influence Microsoft to apply 
 the inverse.
 As far as I'm concerned windows got it _right_ and linux got 
 it... 'linux'.
 I like DLL's being self contained modules with tightly 
 controlled
 interfaces. And deadalnix lists important points.
Apr 11 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, April 11, 2012 14:11:49 Paulo Pinto wrote:

 And as I noted on my post, Windows is not alone in this regard.
 
 Many other OS follow the same explicit export principle, AIX
 being one of them.
 
 Linux != UNIX


I never said that it was. I'm just saying that I consider explicit exporting 
to be a usability nightmare and therefore an enormous mistake, and the fact 
that Windows does it is horrific. The fact that Linux doesn't is fantastic. 
Other *nixes may do it, but that doesn't make it any better of an idea IMHO.

- Jonathan M Davis
Apr 11 2012
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 11 Apr 2012 11:56:00 +0200
schrieb deadalnix <deadalnix gmail.com>:

 
 It isn't a misfeature. The link explain why it is interesting :
   - It improves load time of DSO.
   - Allow more optimizations.
   - Reduce DSO size by 5% to 20% for C++. Considering how long
 mangling are in D, probably more for us.
   - Reduce name collision (this one poorly apply to D, because the 
 module system handle that quite nicely).
 
 Additionally, it allow automatic finalization for non exported
 methods in D.
 


This explains why symbol visibility is useful. But do we really need
'export'? Are there cases where public = export, private/package =
'not exported' wouldn't work? 

When do you actually need 'not-exported' and public? And would export
private/export package be valid?
Apr 11 2012
next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 11/04/2012 19:03, Johannes Pfau a écrit :

 Am Wed, 11 Apr 2012 11:56:00 +0200
 schrieb deadalnix<deadalnix gmail.com>:

 It isn't a misfeature. The link explain why it is interesting :
    - It improves load time of DSO.
    - Allow more optimizations.
    - Reduce DSO size by 5% to 20% for C++. Considering how long
 mangling are in D, probably more for us.
    - Reduce name collision (this one poorly apply to D, because the
 module system handle that quite nicely).

 Additionally, it allow automatic finalization for non exported
 methods in D.


 This explains why symbol visibility is useful. But do we really need
 'export'? Are there cases where public = export, private/package =
 'not exported' wouldn't work?

 When do you actually need 'not-exported' and public? And would export
 private/export package be valid?


public and export aren't the same thing.

If public qualify how the symbol can be acessed by code, export qualify 
how the symbol can be linked. An exported symbol can be linked at 
runtime, but a non exported symbol cannot.

If public = export, then drawback expressed above will occur. If 
protected = not exported, then you cannot extends a class from you main 
application in a DSO (or the other way around). You usually don't want that.
Apr 11 2012
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 11.04.2012 19:03, schrieb Johannes Pfau:

 Am Wed, 11 Apr 2012 11:56:00 +0200
 schrieb deadalnix<deadalnix gmail.com>:

 It isn't a misfeature. The link explain why it is interesting :
    - It improves load time of DSO.
    - Allow more optimizations.
    - Reduce DSO size by 5% to 20% for C++. Considering how long
 mangling are in D, probably more for us.
    - Reduce name collision (this one poorly apply to D, because the
 module system handle that quite nicely).

 Additionally, it allow automatic finalization for non exported
 methods in D.


 This explains why symbol visibility is useful. But do we really need
 'export'? Are there cases where public = export, private/package =
 'not exported' wouldn't work?

 When do you actually need 'not-exported' and public? And would export
 private/export package be valid?



For example, a so/dll might be composed of several D packages. In those
packages you want the public symbols to be visible between packages, but
not visible to the applications that link to your so/dll library.

This is why many languages make a distinction between modules and 
packages. Usually a module is composed of several packages.

These type of modularity might seem complex, but actually is a good way
to modularize applications.
Apr 11 2012
parent Johannes Pfau <nospam example.com> writes:
Am Wed, 11 Apr 2012 20:27:31 +0200
schrieb Paulo Pinto <pjmlp progtools.org>:


 Am 11.04.2012 19:03, schrieb Johannes Pfau:

 Am Wed, 11 Apr 2012 11:56:00 +0200
 schrieb deadalnix<deadalnix gmail.com>:

 It isn't a misfeature. The link explain why it is interesting :
    - It improves load time of DSO.
    - Allow more optimizations.
    - Reduce DSO size by 5% to 20% for C++. Considering how long
 mangling are in D, probably more for us.
    - Reduce name collision (this one poorly apply to D, because the
 module system handle that quite nicely).

 Additionally, it allow automatic finalization for non exported
 methods in D.


 This explains why symbol visibility is useful. But do we really need
 'export'? Are there cases where public = export, private/package =
 'not exported' wouldn't work?

 When do you actually need 'not-exported' and public? And would
 export private/export package be valid?


 
 
 For example, a so/dll might be composed of several D packages. In
 those packages you want the public symbols to be visible between
 packages, but not visible to the applications that link to your
 so/dll library.
 


OK, I understand. I still can't think of a concrete example where I
would want that behavior, but I'll just trust you all that it's useful.


 This is why many languages make a distinction between modules and 
 packages. Usually a module is composed of several packages.
 
 These type of modularity might seem complex, but actually is a good
 way to modularize applications.
Apr 12 2012
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 11 April 2012 at 17:03:48 UTC, Johannes Pfau wrote:

 This explains why symbol visibility is useful. But do we really 
 need 'export'? Are there cases where public = export, 
 private/package = 'not exported' wouldn't work?


I want to sort of hijack export for my web apps. Say
you have

public Data getUserData(string userId, string key) {}

export Data getData(string key) {}

so other modules, internal to the app, are allowed
to replace the user id but still get the nice
function, but external api consumers can only get data
for the user they are logged in as.
Apr 11 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, April 11, 2012 14:29:42 Manu wrote:

 Apply the same rules to Linux, and it'll never bother you again. It's the
 only solution, you can't possibly influence Microsoft to apply the inverse.


That doesn't fix the problem. It just makes it so that Linux has it as well.

- Jonathan M Davis
Apr 11 2012
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
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.
Apr 19 2012
prev sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Tuesday, 10 April 2012 at 17:34:25 UTC, deadalnix wrote:

 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.


TDPL is opposite about this issue. It clearly states that it is a 
top of permissive access. Currently dmd rejects both export and 
for example private, or public. Whether library files are 
compiled separately or not (because of the D module design) an 
importer always see an imported module as a source code and it 
doesn't care whether linker hides symbol or not.

If you order compiler and linker to hide any symbol which is not 
exported (with export keyword) following problem occures:

lib.d:
export class Export {}
public class Public {}
...

main.d:
import lib;

void main()
{
	auto e = new Export();
	auto pub = new Public();
	e.test();
	pub.test(); // am i compiled as a library or part of executable?
}
Apr 19 2012