Code That Says Exactly What It Means

[Peter C]

On Wednesday, 29 October 2025 at 16:18:22 UTC, Paul Backus wrote:
>
> ..
> Managing overall language complexity is the #1 challenge in 
> language design. If you don't take this seriously, your 
> language ends up like C++ or Perl--a huge mess that nobody 
> really understands completely. (You could argue that D has 
> already crossed this line, but even if that's true, it doesn't 
> mean we should make it worse.)
>
> Even features that are small and simple in isolation can add up 
> to an enormous amount of complexity if you accumulate too many 
> of them (see: Perl). So the fact that this individual feature 
> is relatively simple is not a strong counterargument.

There is nothing complex about scopeprivate. That's yet another 
strawman arguement.

scopeprivate fits absolutely perfectly with D's principle: "make 
things open by default, restrict them only when you mean to."

it also fits absolutey perfectly with the principle that: 
"Collaboration does not disolve ownership" - which already 
applies with to private, package and public - with the 
unfortunate scenario that it suddenly no longer applys anymore 
when more than one type is within a module, or a type and a 
helper method, or a type and a unittest.

scopeprivate restores a consistency mental model.

It's also about balancing the safe use of a type, with practical 
collaboration. It's a little bewildering to my why that would be 
so controversial.

And really, if scopeprivate produces cognitive overload in a 
programmers brain, they probably should choose another profession.