Small troubles with "private"

[Timon Gehr]

On 11/05/2013 05:00 PM, 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

How about just adding full granularity?

By condition:

@visibleIf!true                         // public
@visibleIf!(isSubtypeOf!(typeof(this))) // protected

By explicit enumeration:

@visible!(getModule!(typeof(this))) // private
@visible!(typeof(this), T) // visible to type 'T'
@visible!(typeof(this)) // 'super private'
@visible!foo // only (member) function 'foo' can access it
@visible!() // nobody can access it