On Sunday, June 30, 2019 11:24:03 AM MDT Robert M. Münch via Digitalmars-d-
learn wrote:
> I have a case, with templates, where an assert in a unittest can access
> a private memember and I don't know how this can happen.
>
> Before trying to creat an equivalent case, I want to cross-check, if
> assert has special semantics in a unittest so that it can access
> private memembers?
I know that there at least used to be a bug where templates were treated as
public instead of private, though I thought that that was fixed some time
ago. Regardless, as the others have pointed out, private in D is private to
the module, not the class or struct or template or whatever. So, if your
unittest block is in the same module as what you're testing, it legitimately
has access to all private members, and that's not a bug. On the other hand,
if your unittest block is in another module from the declaration, and it's
accessing a private member, that that is a bug unless you're using template
mixins to mix the code into the current module.
D treats the module as the unit of encapsulation so that it doesn't have to
worry about having features like C++'s friend, and in general, this has
worked out extremeley well, though it tends to surprise many people at
first, since many (most?) don't read the documentation carefully enough and
assume that private is private to the class as it is in many other
languages:
https://dlang.org/spec/attribute.html#visibility_attributes
Certainly, it's great in general that unittest blocks can access private in
the same module, because it makes it easy to test private functions without
having to alter the API of your class like you would with something like
JUnit in Java. If for some reason, you really do need something to not have
access to private members, then you need to put it in a separate module.
- Jonathan M Davis
