Code That Says Exactly What It Means

[Peter C]

On Wednesday, 29 October 2025 at 19:59:15 UTC, jmh530 wrote:
>
> ...
> The complexity I would be more worried about is the impact on 
> the compiler code base. I don't have the ability to speak to 
> that, but I take people like Dennis and Walter at their word 
> that it's something to be concerned about. But if the argument 
> against it is that complexity will increase, then the argument 
> carries more weight if we can spell out more concretely how it 
> will increase.

Here there may well be an argument to make. Although it took me 
less than an hour
to implement scopeprivate, I cannot really judge its impact on 
the rest of the compiler code. So I agree, that could be a 
concern.

But even then, is that a problem with the idea of scopeprivate, 
or the complexity in the compilers code, or the enourmous amount 
of features it already has to implement.

I'd say the 'idea itself' - of scopeprivate, is the less 
concerning issue here.

>
> This complexity vs. expressiveness trade-off shows up in a 
> number of places in D ...

It's also about local reasoning, which is hard to do when the 
encapsulation barrier of the module supercedes the encapsulation 
barrier of your type.

Swift made the same mistake - and had to correct it. Good on them 
for having the courage to go all the way, instead of just 
implementing scopeprivate (i.e. reverting private to what the 
mental model that programmers held, and introducing fileprivate.

Here's a nice talk, although a little drawn-out, about the 
importance of being able to reason locally.

https://youtu.be/bhizxAXQlWc