Access visibility and linkage

Arun Chandrasekaran aruncxy at gmail.com
Thu Feb 15 06:43:52 UTC 2018


I was reading through 
https://wiki.dlang.org/Access_specifiers_and_visibility#What_is_missing

> There is currently no way in D to mark symbols for internal 
> linkage, saying "this an implementation detail, you should not 
> even know this one exists". This is an important module-level 
> encapsulation tool which also somewhat guarantees that those 
> symbols can't be linked to by accident by some other module and 
> you are free to change them keeping binary interface same.

DMD v2.077.1 exhibits the same behavior. Is this is already being 
worked on? Or is there any plan to address this? Can this be 
fixed? If so how? If not, why not?

> Name clash between public and private symbols has also been 
> stated as unneeded and useless feature that makes possible to 
> break a compilation of a project by changing private name. It 
> is also impossible to use an UFCS function now if class already 
> has private one with same signature.

Also, why is the default visibility of global variables at module 
level public Shouldn't they be private by default to provide 
better encapsulation guarantee (and linkage guarantee if the 
above is addressed in future)?
 From readability point of view as well, for instance, if I want 
to know all the functions "exposed" by the current module, I can 
simply grep for public.


More information about the Digitalmars-d-learn mailing list