Export ?

[Maxim Fomin]

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?
}