Code That Says Exactly What It Means

[Peter C]

On Monday, 27 October 2025 at 11:22:33 UTC, Serg Gini wrote:
>
> ..
> D design team doesn't ignore it, but against this feature.
> ...

They're against locks on doors?

The Building Analogy (of D):

     Offices = Classes or Types Each office represents a type 
(like a class or struct). Inside the office are documents 
(fields, methods, data).

     Locks on doors = Access Modifiers (i.e. scopeprivate) This 
lock lets you decide who can enter. You can keep sensitive 
documents private (scopeprivate) while still working in the same 
building.

     No locks allowed = No type privacy. If the language doesn’t 
support scopeprivate members, then anyone can walk into any 
office and read or change the documents.

     Separate buildings = Modules or Packages. To achieve 
scopeprivacy, you’d have to move the sensitive office into a 
completely different building. That way, only people with access 
to that building can see it.

But this workaround is just clumsy compared to simply locking the 
door.

D doesn't let you lock the office door, so your only option is to 
move the office into another building - but that’s a poor 
substitute for a real lock.

Most people (programmers) already expect to be able to have a 
lock on their door, and also the freedom to not have it when so 
desired. So this is something D will need to grapple with, 'if' 
it ever becomes widely used.

I think that is the lesson of Swift - not to underestimate the 
power of the mental model that a large portion of programmers 
already have - a model that provides clarity in complexity.

I could restore my own mental model of programming, somewhat, by 
starting my D coding with this template:

module someModule;
@safe:
private:

public class myPublicClass
{
   scopeprivate:

}