• Arun Chandrasekaran (12/23) Feb 14 2018 DMD v2.077.1 exhibits the same behavior. Is this is already being
• Seb (7/24) Feb 14 2018 AFAICT it's a feature as the article correctly explains this
• Arun Chandrasekaran (4/21) Feb 15 2018 ah, not to that extent though.. just need all my variables and

Arun Chandrasekaran <aruncxy gmail.com> writes:

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.

Seb <seb wilzba.ch> writes:

On Thursday, 15 February 2018 at 06:43:52 UTC, Arun 
Chandrasekaran wrote:
 I was reading through 
 https://wiki.dlang.org/Access_specifiers_and_visibility#What_is_missing

 [...]

 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?

AFAICT it's a feature as the article correctly explains this 
doesn't work well with serialization:

 Compile-time reflection, i.e. serialization libraries or 
  attribute scanners. Limiting access for __traits may forbid 
 certain currently working idioms.

Use Voldemort types if you want to truly encapsulate something.

 [...]

 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.

It's a sensible default for most libraries and problems.
Simply use `private:` if you think otherwise.

Arun Chandrasekaran <aruncxy gmail.com> writes:

On Thursday, 15 February 2018 at 06:52:15 UTC, Seb wrote:
 On Thursday, 15 February 2018 at 06:43:52 UTC, Arun 
 Chandrasekaran wrote:
 I was reading through 
 https://wiki.dlang.org/Access_specifiers_and_visibility#What_is_missing

 [...]

 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?

 AFAICT it's a feature as the article correctly explains this 
 doesn't work well with serialization:

 Compile-time reflection, i.e. serialization libraries or 
  attribute scanners. Limiting access for __traits may forbid 
 certain currently working idioms.

 Use Voldemort types if you want to truly encapsulate something.

ah, not to that extent though.. just need all my variables and 
functions to be private at the module level.

 Simply use `private:` if you think otherwise.

Thanks! Turtles all the way "up" this time :)