Code That Says Exactly What It Means

[Peter C]

On Thursday, 30 October 2025 at 03:48:01 UTC, Steven 
Schveighoffer wrote:
> On Thursday, 30 October 2025 at 03:00:02 UTC, jmh530 wrote:
>> On Wednesday, 29 October 2025 at 21:01:03 UTC, Sergey wrote:
>>> [snip]
>>> have different "weight" than from "first time forum poster 3 
>>> days ago" or from forkit/claptrap.
>>>
>>> That's why the comparison of the situation with i-strings 
>>> when it was a discussion between Paul, Adam, Steven, Timon 
>>> and Walter has nothing to do with messages that popping up 
>>> every year from the same one single person.
>>> So the pushback in the current situation is understandable.
>>>
>>
>> Are they the same person? I can't keep track. People should 
>> just stick with one ID. If it's just one person making a big 
>> deal about this, then it would change the calculus.
>
> I think it's unfair to judge all new questions with this lens, 
> it's showing a bias that is not really focused on the topic at 
> hand.
>
> Yes, there was an individual who posted with multiple account 
> names, and this person continually brought up "scopeprivate" or 
> "private(this)" or whatever new incarnation of this tired idea 
> that D should adopt lest it leave behind the millions of 
> developers just waiting to use the language as soon as this 
> gets fixed. But I'm not totally convinced this latest handle is 
> the same person, I will at least give that benefit of doubt.
>
> But that doesn't mean we have to keep entertaining the idea 
> when it's been discussed to death.
>
> Bottom line: D has module private (similar to Java), and this 
> is not going to change, no matter how many pleas are posted 
> here.
>
> There has always been only ONE deficiency for this, and that is 
> documented unittests being allowed to use private symbols in 
> the module. But this is a unittest problem, and not a private 
> problem.
>
> Note that the OPs argument against (non-documented) unittests 
> being able to access private data is ironically something I 
> view as a necessity -- I often test functions on a type and 
> then examine the private details to make sure the state is as I 
> expect it.
>
> This is the last time I'll post on this thread. And probably it 
> should just be dropped.
>
> -Steve

unittests being able to access private data should be put within 
the scope of the type with that data. This presents a consistent 
mental model of encapsulation.

My grip with D, is the mental model of encapsulation (that 
literally millions of programmers already have), is discarded 
just so D can say 'the module is the unit of encapsulation'.

There is nothing wrong with D saying instead:

That the module is the unit of encapsulation, however, 
user-defined types (specifically class and structs), can continue 
to maintain their own invariants when required, by using 
scopeprivate, and thus the two principles of (1) 'collaboration 
does not disolve ownership' and (2) 'make things open by default, 
restrict them only when you mean to', continue to remain true.

To me, that is really not a contraversial idea.

What is controversial to me, is that a module disolves the 
encapsulation of types.

Perhaps what D should advertise instead, is:

"The module is the unit of encapsulation in D, and thus it 
disolves the encapsulation of types".

Good luck getting an audience with that ;-)