Preparing for the New DIP Process

[Jordan Wilson]

On Saturday, 27 January 2024 at 10:42:26 UTC, FairEnough wrote:
> 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.

I said "explicit class privacy", I was meaning the concept you 
are talking about (it probably wasn't the most accurate phrase).

> 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).

By offering counter questions, I was trying to make a point about 
the line of questioning itself. But I'll answer anyway.

> (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)?

I have not come across such a circumstance personally, during my 
time with languages using higher level encapsulation (D module / 
Go packages). I can certainly imagine that some would have that 
need for a particular situation, but I can't think of it.

I believe we are now in the "there is nothing more to be said" 
territory (just for the record, I think we both agree the feature 
is good, I just don't think the feature is necessary at 
all...nice-to-have at best. I suspect we'll agree to disagree).

Jordan