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.
