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
