Preparing for the New DIP Process

[FairEnough]

On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson wrote:
>
> ...
> I suspect the proportion of users that really care about 
> explicit class privacy and find the workaround of putting a 
> class that needs such privacy into a separate file untenable, 
> will remain the same.
>
> Jordan

Well D already has class privacy. Would be absurd if it didn't.

So this is not about class privacy per se, nor is it about OOP.

It's about whether D should provide an *option* for class privacy 
within a module, so that the programmer can use it when it is 
appropriate (e.g. there is other code in the module as well, 
perhaps even just a unittest, and the programmer wants the 
compiler to enforce type safe use of that type within that 
unittest).

But still none of what you said addresses the questions I put 
forward. Answers to those questions will form the basis for a 
need (or not), for private(this).

(Q1) Are there any circumstances where a class type might need to 
retain control over its state from other code within the same 
module (including unittest code)?

(Q2) What problems could potentially occur when a class types 
state is always leaked into the module.

If your answer to Q1 is no, then there is nothing more to say.

If your answer to Q1 is yes, but in this case just put the type 
in its own module, then you've not really answered the question, 
since there would be no other code in the module.

If your answer to Q2 is none, then there is nothing more to say.

If your answer to Q2 identifies one or potential problems, you 
have an immediate type safety concern that needs to be addressed, 
somehow. There is no language feature to help you deal with that 
problem (i.e have the compiler enforce your design). You simply 
have to avoid putting any other code in the same module (this 
includes your unittest code).

So D's approach to answering these two questions, is you should 
prevent the circumstance from ever arising by constraining your 
design to one type per module, and the unittest for that type in 
its own separate module as well. That will be acceptable to some, 
and not others.

It also raises a final question of whether that is all the D 
programming language should ever provide to the programmer - a 
way to avoid these situations by constraining your design.

If you answer yes, there is obviously nothing more to discuss.

If you answer no, then what can be done about it?

As I've mentioned, I think Swift got the balance right.