`restricted` member variables

[Mike Parker]

On Thursday, 23 June 2022 at 00:31:52 UTC, forkit wrote:

> the argument that you have access to the module, and accidents 
> won't happen, or 'just don't do it', is nonsensical.
>

I never said accidents won't happen. In fact, I'm sure I 
explicitly called this out as a real potential problem I see with 
private-to-the-module (especially when multiple people work on 
it). But I also noted that the same problem exists *within* the 
class because you can access any private member from any class 
method. There is absolutely no practical difference here.

One of the Effective Java books (IIRC, might have been a 
different book) pointed this out. If multiple methods modify a 
private member, then you can't maintain an invariant on that 
member. Java doesn't have built-in support for invariants like D. 
The recommended solution? Always modify members through a setter. 
But according to you, that's a problem because accidents can 
happen.

In D, the `invariant` feature allows you to maintain the 
invariants of any class from within the class. A class in its a 
module by itself is fully 100% encapsulated and the invariants 
are guaranteed. So if you have invariants you don't want 
violated, then put that class in its own module.