Code That Says Exactly What It Means

[Peter C]

On Tuesday, 28 October 2025 at 02:28:41 UTC, Walter Bright wrote:
> I know you didn't propose this, but I had quite enough of C++'s 
> "friend" classes. I've never missed that misfeature in D.

There is nothing conceptually wrong with the C++ friend concept. 
It provides a controlled exception, where you can grant access 
only to specific functions or classes, without opening everything 
up. It balances strict encapsulation with practical flexibility. 
Something that you yourself clearly recognise as being important 
in D as well.

In C++, the actual problem was not the friend keyword, but rather 
the programmers who misused it, which lead to poor design and a 
blurred abstraction boundary.

If D didn't have the class type, I'd say that D solved this 
problem rather nicely.

But a class type also has an abstraction boundary -> it's *own* 
scope.

Without appropriate scope rules, you can't enforce that boundary, 
and you lose encapsulation - and encapsulation is the foundation 
of abstract data types.

Then, the distinction between interface and implementation 
collapses.

Then, the type's internal rules are meaningless - the abstraction 
collapses, the type becomes harder to reason about, everything 
becomes global, its internal state leaks into the rest of the 
module, breaking any guarantees that the type is supposed to 
enforce.

Without scope, your type just becomes a bags, that anyone can 
poke into, undermining abstraction, modularity, and reliability.

Like with C++ friend, the programmers is invited to misuse it, 
leading to poor design and a blurred abstraction boundaries.

So there is no alternative now, but to create 'one-class modules'.

'scopeprivate' could remove all of these problems, and wouldn't 
force any change on anyone.

Although during a code review, I'd be asking myself, why has this 
programmer decided to use private instead of scopeprivate - and 
there better be a bloody good reason for it!