Small troubles with "private"

[Meta]

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.

Would the package access specifier work for this, as long as you 
keep it in the same package? 
http://dlang.org/attribute.html#ProtectionAttribute

> 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.

I've seen Jacob Carlborg suggest that unittests should be put in 
a separate module before, maybe this is an argument for that, 
even in smaller projects.

> 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.

I think this would be confusing for people coming from Java, C#, 
and C++ as well, but I think it's just something you have to 
learn when using D. I think that even if they don't know about 
it, they'll come across it pretty quickly.

> 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.

I think this might add too much complication for the small 
benefit. Programmers would have to consider yet another access 
specifier when adding struct/class variables. It seems like 
unnecessary mental overhead for something that can be avoided 
fairly easily.