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
