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.

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.

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