Code That Says Exactly What It Means

[Peter C]

On Tuesday, 28 October 2025 at 02:41:51 UTC, Walter Bright wrote:
> On 10/27/2025 6:19 PM, jmh530 wrote:
>> To be fair, it keeps coming up because people (not me!) say 
>> they want the feature and the reasons for being opposed to it 
>> have never been that great. The people opposed say D’s unit of 
>> encapsulation is the module, great, but what you’re really 
>> doing is presuming a paradigm of programming that is different 
>> from how they want to work. If D advertises itself as a 
>> multi-paradigm language that supports object-oriented 
>> programming and a bunch of object oriented programmers say 
>> they want scopePrivate / privateScope (and several get upset 
>> and leave the community), then it doesn’t really come across 
>> as that supportive of the paradigm.
>
> D is also regularly accused of supporting too many paradigms.
>
> For example, GC is optional in D. But some people do not want 
> it optional, they want it to not be there. Hence, -betterC. But 
> D gets criticized for that, too.
>
> There's no way to please everybody. I wish there was.
>
> I've programmed first in BASIC, then Fortran, then C, then C++, 
> then Java, then Javascript, then D.
>
> My first Fortran programs looked like BASIC. My first C 
> programs looked like Fortran, and so on.
>
> It's always off-putting at first, until it becomes natural and 
> you're done with the previous way for good.
>
> In the olden days, file lookups were slow and it made sense to 
> cram it all into a small number of source files. Those days are 
> long gone now, and IDEs make navigating multiple source files 
> super easy. Having the unit of encapsulation being the file 
> which is the same as the module makes a great deal of sense.
>
> I.e. if you have a 10,000+ line module, it's likely time to 
> consider dividing it into distinct modules, rather than 
> dividing up the scopes in the file.

I think you're missing the point here.

public class BankAccount
{
     private double balance;   // hidden?
     public void deposit(double amount) { balance += amount; }
     public double getBalance() { return balance; }
}

A typical programmers mental model of this type is:

"I can deposit and check balance, but I cannot directly mess with 
the balance field."

But in D, this mental model no longer holds - for those millions 
of programmers who share the same mental model as I do - when 
other code is within the same module (even just unittests!)

The internal state of this type, in D, 'automatically' leaks into 
the rest of the module.

D does not give the programmer explicit control over this. The 
language itself takes control.

Cognitive load is automatically increased, as the programmer 
needs to study the details of the other code in the module, to 
see when this types 'apparent' contract holds, and when it does 
not.

Cognitive Load Reduction:

With 'scopeprivate', the programmers desire to restrict access to 
a member does not need to be 'simulated' through 'one class 
modules', or via _conventions. And, the internal state of these 
scopeprivate members would no longer 'automatically' leak into 
the rest of the module.

scopeprivate is not some weird concept.

Millions of programmers using the most widely used languages 
today (and even some of those being developed as successor 
languages - Carbon for example), already have this mental model.

Swift's mental-model-breaking implementation of private, was also 
controversial in the early stages of its development/evolution. 
Personally, I think they should have left private as they 
originally implemented it in Swift (meaning private to the file), 
and just added scopeprivate. That would have avoided a lot of the 
controversy over the change, and everyones code would have still 
compiled just as it did before they added scopeprivate.

So, getting back to my initial point - for you to dismiss the 
idea of scopeprivate, as 'well, you can't please everybody', just 
sound disingenous to me.

What is the reason then?

I can probably rule out one - It's too difficult/complex to 
implement and maintain?

Well, with no compiler experience whatsoever, I was able to 
implement scopeprivate in less than an hour. None of my extensive 
tests have (yet) shown even the slightest problem with my 
implementation. I've actually found it very pleasant to work with 
- better than 'private(this)', and I can just use "scopeprivate:" 
at the start of class type (so only ever need to type it once per 
class implementation.

Conceptually, it works well as it fits my mental model, and 
programmatically it works well also. The module boundary of the 
member is not affected, unless the programmer opts-in to using 
scopeprivate. There are no breaking changes. Everyones code will 
still compile. So what's the problem then?

Slightly off topic now:

Here is a nice talk - https://youtu.be/gG4BJ23BFBE - regarding 
C++'s need for a successor.

Even after more that two decades of devlopment, the D Programming 
Language didn't even get a single mention. It's not that it was 
mentioned and then discarded as not being a suitable succesor for 
this or that reason, it just wasn't mentioned. Not even a mention 
from the audience at question time. This was just last year! I 
was pretty suprised by this actually.

I'd love to ask Helge Penne why he never mentioned the D 
Programming Language.