We need an internal keyword.

[12345swordy]

On Monday, 22 October 2018 at 11:06:42 UTC, Jonathan M Davis 
wrote:
> On Monday, October 22, 2018 2:30:21 AM MDT Basile B. via 
> Digitalmars-d wrote:
>> On Monday, 22 October 2018 at 08:25:17 UTC, Andrea Fontana 
>> wrote:
>> > Moreover: you're the author of the module so you're supposed 
>> > to know how it works and which members you should call or 
>> > not.
>>
>> - team
>> - maintainer of a module written by someone that works 
>> elsewhere
>> now.
>>
>> that's two cases where strict privacy can be optionally a 
>> thing avoiding wrong usage of private members within the scope 
>> of a module.
>
> Part of the point is that if the module is large enough that 
> the folks working on the code can't actually keep track of 
> what's in it, then it's too large, and as such, if you need to 
> protect your class or struct members from the rest of the 
> module, then it really should be in a separate module for the 
> code to be properly maintainable anyway. Yes, having multiple 
> people involved makes the problem worse (especially when some 
> of them join the team later), but it doesn't fundamentally 
> change the issue. If it changes anything, it simply makes the 
> argument stronger for preferring smaller modules so that 
> they're easier to digest.
>
> Personally, I've found that larger modules have worked just 
> fine for me without having to worry about these sort of 
> encapsulation issues. It simply isn't a problem, and I don't 
> recall ever seeing a bug because of it. But anyone who's 
> worried about it always has the option of simply going for 
> smaller modules, and the encapsulation problem is already 
> solved without making the language any more complicated. Plenty 
> of folks already think that it's best practice te prefer 
> relatively small modules anyway, and if you need a way to 
> protect your private member variables from the module when the 
> module isn't large, then you're definitely doing something 
> wrong.
>
> Given the D philosophy that the module is the primary unit of 
> encapsulation and that you should at least roughly understand 
> the entire module when working on it (or it's almost certainly 
> too large), having an access level to protect member variables 
> from the rest of the module simply makes no sense. Anyone who 
> feels the need for such an access level think about what 
> they're doing with their code and why they feel the need for it 
> - whether it's simply because they're used to it from other 
> languages, or because they're organizing their code in a manner 
> which is detrimental to maintainability.
>
> - Jonathan M Davis

Here is the intial dip draft: 
https://github.com/12345swordy/DIPs/tree/Encapsulation
If Walter Bright insist that the module is the unit of 
encapsulation then I propose we get rid of the "one module per 
file" restriction, by introducing sub modules.

-Alex