how to make private class member private

[Steven Schveighoffer]

On 3/17/18 5:56 AM, Nick Treleaven wrote:
> On Tuesday, 13 March 2018 at 13:59:00 UTC, Steven Schveighoffer wrote:
>> If you limit to class members, then you have to do something like C++ 
>> friends, which are unnecessarily verbose.
> 
> Not if you also have a module-level visibility modifier, which could 
> have been `module`.

If we could go back in time and talk with a young Walter about the 
consequences of choosing the scheme the way it is, maybe he might have 
made different choices, but at this point, it's hard to change it.

Note, again, you can do pretty much every privacy scheme you want with 
package modules today. Before, it was a lot less nice.

It's pretty simple: all your friends go into the module. All your 
external functions that should only use the public API have to go 
elsewhere. I think the thing that bites people is simply that they 
aren't used to it.

> 
>> IMO, the module-level encapsulation is the right choice. It helps with 
>> a lot of key features:
>>
>> 1. IFTI factory methods
> 
> Aren't these mainly because constructors can't use IFTI, unlike C++17, 

While this is a limitation that I wish wasn't there, constructors aren't 
always the best way to build a type.

But there are other reasons to put functions that access private pieces 
outside the aggregate. For instance, if you want to accept a struct by 
value.

> 
>> 2. unittests
> 
> Documented unittests should not be allowed to use private symbols, I 
> just filed this:
> https://issues.dlang.org/show_bug.cgi?id=18623
Why not?

unittest
{
    auto foo = new Foo;
    assert(foo.internalbuffer.empty); // note, this is a private symbol.
}

I can do the same thing in ddoc, but without the benefit of having the 
unit test run. Forcing me to do it that way is just annoying (I will 
have to duplicate the code).

-Steve