Preparing for the New DIP Process

[FairEnough]

On Thursday, 25 January 2024 at 00:19:54 UTC, Jordan Wilson wrote:
>
> ...
> That wasn't what was said. What was said was "causing US 
> problems". I.e. on the whole, the lack of class-level privacy 
> does not appear to be causing widespread problems, which 
> implies that it's simply lower on the list of feature requests 
> for most people.
>

Allowing mutable state to escape - the confines of the type in 
which it has been declared - into the whole of the module, will 
inevitably lead to a problem.

My first use of the D language demonstrated that this statement 
is factual.

The more 'widespread' D is used, will 'likely' also demonstrate 
the same.

Having a means to control what state can or can't escape into the 
rest of the module seems like a pretty sensible option to have - 
at least to me.

Again, the only argument that has been put forward against this, 
is that in D you can put your type into its own module. That is, 
one module for every class, and for every unittest.

That can end up to be a lot of files needing to be managed, 
simply to control the escape of state into a module.