Small troubles with "private"

[bearophile]

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