On Sunday, 18 March 2018 at 18:04:13 UTC, Tony wrote:
> On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote:
>
>>
>> D is not C++, C#, or Java. C++ uses friend to get around the issue. Java has no solution. I don't know about C#.
>>
>
> Java has four protection levels. If you don't explicitly specify [private, protected, public] the protection level is implicitly "package-private". That means that any class in the same package can access that attribute. I believe that Java packages are identical to D packages.

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/accessibility-levels

C# has 6 accessibility levels:

public - Access is not restricted.
protected - Access is limited to the containing class or types derived from the containing class.
private - Access is limited to the containing type.
internal - Access is limited to the current assembly.
protected internal - Access is limited to the current assembly or types derived from the containing class.
private protected - Access is limited to the containing class or types derived from the containing class within the current assembly. Available since C# 7.2.

What is a C# Assembly? Someone says on a forum:
"An assembly is a "unit of deployment" for .NET, almost always a .exe or .dll.
In C# terms, it's basically a single C# project."

And also refers to
https://social.msdn.microsoft.com/Forums/en-US/088ce8ed-ef9b-4dea-88b3-ca016885e26d/what-is-an-assembly-in-terms-of-c?forum=csharplanguage
which says:
"Assemblies are the building blocks of .NET Framework applications; they form the fundamental unit of deployment, version control, reuse, activation scoping, and security permissions. An assembly is a collection of types and resources that are built to work together and form a logical unit of functionality. An assembly provides the common language runtime with the information it needs to be aware of type implementations. To the runtime, a type does not exist outside the context of an assembly."

On Sunday, 18 March 2018 at 11:12:46 UTC, Alex wrote:
>
> ´´´
> Are there any scenarios in which the person writing the class, would want to encapsulate their class, or some parts of it, from the rest of a module (while being forced to put the class in this module)?
> ´´´
>
> The answer is no. As the person which is writing the class has always the power to decide which module to edit to put the class in.
>
> And due this fact, the statement
>
>> The fact is, the creator of the class is also the creator of the module..
>
> is the coolest semantic statement of the whole thread so far, I think :)

Well, it seems to me, that the only real objection one can have to improving encapsulation within a module, is objecting to improving encapsulation within a module.

The fact that the creator of a class, is also the creator of the module that contains that class, is not a valid reason for not seeking to improve encapsulation of that class.

On Sunday, 18 March 2018 at 18:45:23 UTC, Steven Schveighoffer wrote:
>
> 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.
>

I think this highlights the real problem with D.

Power is too centralised, and kinda arbitrary.

I'm going back to Java ;-)

On Monday, 19 March 2018 at 01:11:43 UTC, psychoticRabbit wrote:
> The fact that the creator of a class, is also the creator of the module that contains that class, is not a valid reason for not seeking to improve encapsulation of that class.

I agree with this. This especially matters with projects where multiple people might work on the same module. You might not want to expose every member to all the people who work on the module. Whereas you might want other members to be exposed to the module and not outside, so the argument for putting the class into a new module doesn't work either, since the members you do want to expose cannot be exposed, unless they're public, in which case it defeats the whole purpose of encapsulation.

Yes, it's great that private is module-level by default, but it just doesn't work in practice with modules worked on by multiple people.

Tons of bugs can be avoided too, like a few times unittests have passed in phobos with traits because private members were visible in the module. (I can't remember a specific example on top of my head, but it has happened a few times.)

On Sunday, 18 March 2018 at 18:45:23 UTC, Steven Schveighoffer wrote:
> unittest
> {
>    auto foo = new Foo;
>    assert(foo.internalbuffer.empty); // note, this is a private symbol.
> }

I don't understand why you would want a private symbol in a *documented* unittest, the reader of the *documentation* will not be able to run the example code.

> I can do the same thing in ddoc, but without the benefit of having the unit test run.

You mean not using a unittest?

> Forcing me to do it that way is just annoying (I will have to duplicate the code).

If you really want your documented unittests not to be runnable by a user, you can have a free function with `protected` access as a workaround.