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:

}

On 10/26/2025 2:35 AM, Peter C wrote:
> But my knowledge of D is somewhat limited - I don't think it even has a decimal type??

I'd just use `long` and have it represent the number of pennies. This gives you representation up to long.max, or:

$92,233,720,368,547,758.07

I.e. $92 quadrillion dollars.

The national debt is currently $38 trillion, and would have to increase in size by a factor of about 2,421 to overflow.

You're good for the foreseeable future!

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.

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.

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.

go the extra mile and delete private and immutable

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.

On Tuesday, 28 October 2025 at 06:47:14 UTC, Peter C wrote:
> Conceptually, it works well as it fits my mental model, and

Good for you!

> 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?

There is no problems as I can see.
You wanted this feature - you've implemented it and now you can use it.
It's not going to happen in upstream D.
You can speak with Adam and try to include it into OpenD.

> Slightly off topic now:
> 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.

The real reason : https://x.com/cyrus_msk/status/1855399721998876761

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!