Module-level privacy

[meppl]

On Sunday, 13 May 2018 at 05:51:07 UTC, KingJoffrey wrote:
> On Sunday, 13 May 2018 at 05:11:16 UTC, Neia Neutuladh wrote:
>> [...]
>
> First, this thread was about extending the capabilities of 
> classes in D with some new attribute/capability - sealed.
>
> I thought it was first important to point out, in this thread, 
> as opposed to a separate thread, that classes in D are already 
> problematic, because modules do not respect the encapsulation 
> boundaries of classes, and any discussion about further 
> extending classes should be approached with great caution - 
> because the problem will only become even more entrenched.
>
> Second, writing a DIP is pointless, since Walter likes the idea 
> that the module doesn't protect the encapsulation boundary of 
> the class. Now if Walter thinks that's fine, what is a DIP 
> going to do? I mean really. I have better things to do.
>
> Third, those who responded to my caution are the ones that 
> should have created a separate thread, not me.
>
> Finally (and I do mean finally), my concern about the loss of 
> the encapsulation boundary of classes in D, has a very real 
> impact on the quality and maintainability of software systems 
> developed in D. That the designer of D apparently thinks 
> otherwise, baffles me.

walter bright was not the only one who liked that idea of "only 
module level encapsulation". Its unfair to imply it like that.
Also, someone may say: I can see what happens in one and the same 
file. If there are two classes/structs in one file, they are 
"friends" and I dont need the "friend"-keyword anymore.
Thats an argument, too.