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?

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On Sunday, 30 June 2019 at 17:24:03 UTC, Robert M. Münch 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?

Private means that only members of the enclosing class can access the member, or
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
members and functions in the same module as the enclosing class.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
did you take it into account?

On Sunday, 30 June 2019 at 17:24:03 UTC, Robert M. Münch 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.

Modules are the units of encapsulation in D:

https://dlang.org/spec/attribute.html#visibility_attributes

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

On 2019-06-30 17:47:27 +0000, a11e99z said:

> Private means that only members of the enclosing class can access the member, or
> vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
> members and functions in the same module as the enclosing class.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> did you take it into account?

Of course not... still to much C++ in my head... Thanks for the clarification. I will remember it from now on.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster