Small troubles with "private"

[Gary Willoughby]

On Tuesday, 5 November 2013 at 16:00:43 UTC, bearophile wrote:
> 1) I usually write more than one class or struct inside each D 
> module, unlike in Java. But sometimes when I move that class or 
> struct elsewhere (during refactoring, or in other situations) I 
> get access errors to private fields. Those errors were already 
> in my code, but I didn't see them because "private" in D means 
> module-private.
>
> 2) My unittests are useful to catch bugs when I run them at 
> run-time, but they are also use to exercise code, this means to 
> actually use it, and catch some bugs statically (instantiating 
> templates, etc). But unfortunately such unittests can't catch 
> protection bugs because most of my unittests are inside the 
> same module, so "private" gets ignored.
>
> 3) A third problem with module-private is that newbies coming 
> from Python, C, and other languages that don't have 
> private/protected attributes and write little experimental D 
> programs, have less chances to _learn_ the true semantics of 
> the privacy attributes until they start to spread their classes 
> in different modules.
>
> How to solve such little troubles? A possible idea is to add to 
> D another attribute, a kind of "private private" that is 
> enforced inside the same module. It could be named "super 
> private" because D has the "super" keyword :-) But this idea 
> doesn't solve all the problems, because sometimes you don't 
> want to use a super private attribute.
>
> Bye,
> bearophile

IMHO private should mean private as enforced by other languages 
and use another keyword for module level privacy. 'internal' 
springs to mind.