We need an internal keyword.

[Jonathan M Davis]

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