Code That Says Exactly What It Means

[Peter C]

On Sunday, 26 October 2025 at 14:55:07 UTC, Steven Schveighoffer 
wrote:
> On Sunday, 26 October 2025 at 06:33:11 UTC, Peter C wrote:
>> Among D developers, the idea of adding a new visibility 
>> attribute like scopeprivate often meets with scepticism. After 
>> all, D already has private for module-level encapsulation and 
>> package for sharing across sibling modules. And if you really 
>> want to lock a class down, you can always put it in its own 
>> module. So why bother?
>>
>> [...]
>
> This has been proposed and rejected many times. In D private is 
> for the module. This is intentional.
>
> -Steve

I'm wouldn't say I'm proposing it, but rather demonstrating how 
it would be useful.

D's philosophy that modules are the true encapsulation boundary, 
is just that, a philosophy.

The code I presented, and the reasoning behind it, is the real 
world, and that is what matters.

I do agree that the module boundary makes complete sense when 
you're dong Rust like programming. But when you are programming 
with objects, based on class types - and come from one of the 
many languages that do support a boundary on the class type - and 
discover that in D the class type has no boundary, the mental 
model of OOP becomes blurred. I believe when Swift became widely 
used, there was some significant pushback on how they blurred the 
boundaries on types. I would expect the same to occur in D, if it 
ever achieved wide spread use.

Imagine you're looking for a new building for your business, and 
you ask the proprietor whether i can put locks on some of the 
offices, and the proprietor says, no you cannot. If you want a 
locked office, you'll need to put it in a separate building.