On Wednesday, 29 October 2025 at 00:19:10 UTC, Kapendev wrote:

Pink Floyds album "The Wall" was about the dark side of object orientated encapsulation. It has it's climax in the song "The Trial" where the wall is final torn down and monkey is simultaneously exposed and freed from his mental prison.

Tear down the wall!

On Tuesday, 28 October 2025 at 23:15:36 UTC, Peter C wrote:

The problem with your approach is that you're proposing a major change to the language. You need to demonstrate the benefit. I'm not proposing anything, just telling you that if you don't want to dump your time in a hole, you're going to need to provide a more compelling argument to the powers in charge (which does not include me). I don't recall anyone ever arguing for this feature and making a real attempt to justify it as a language change.

On Wednesday, 29 October 2025 at 09:17:19 UTC, Serg Gini wrote:

On Tuesday, 28 October 2025 at 22:36:58 UTC, Lance Bachmeier wrote:

I should preface this by repeating again that I really don't care about whether to make this change...

You say it's a "major change to the language". Is it really? I thought private(this) was added to Open D without much difficulty.

The whole argument as I see it is:
a) the proponents saying they want this feature so that other code in a module can't reach into their classes/structs (I don't think there is a good argument that they shouldn't care about this, hence...)
b) the other side saying that the workaround is putting the class into a separate module and importing (there are also - what I view as - secondary arguments that 1) there is a mental complexity budget for the language and 2) each language addition requires thinking about how it impacts all the other features), and
c) the proponents saying they want to organize the code in one module and not split it up.

The proponents could add on that it's a little more complicated than just putting the class into its own module (and it's each class you want to enforce this on). For instance, what if what you want is a module with function A that is used by class B, which you want to be the equivalent of privateScope (or whatever it gets called), and then there is also a function C uses both function A and class B. If you move class B into its own module, then it will need to import the original module to get access to function A. It's considered best practices not to have circular dependencies (and not possible under some conditions), so you may want to move function A into its own module too. So they may have to do more than just move the classes you want to enforce this restriction on into separate modules.

It's also occasionally more difficult to split up code into multiple modules. For instance, what if you are prototyping something in run.dlang.io (impossible I think in this case) or what if you just want a small command line script. Of course the obvious reply is why are you doing something sophisticated enough to require this kind of access control in scripts.

With respect to the secondary arguments:

1. On the mental complexity budget issue, I don't view that as a big issue as it is a convenient extension of the protection modifiers. protected and package are probably more confusing than this.
2. On the language feature interaction issue, maybe this is a concern, but I don't know enough about the compiler internals to say how significant it is. The language already has access modifiers. private is already implemented. This is a more of a limited version of private. I wouldn't think it would cause too many problems beyond those related to private. It would need to be included with the getVisibility trait and I'm not sure offhand how that would impact downstream code.

What I think is the best practical argument against this feature is that making the language change requires people to do it and the people who would usually do it are busy with other things they think are more important. This is a good argument. I think the people who favor this change should be responsible for writing the DIP and getting it implemented. How about DIP approval conditional on implementation? And maybe delayed until after editions are implemented.

On Wednesday, 29 October 2025 at 13:55:42 UTC, jmh530 wrote:

It's a change to the grammar, which means that all parser-based tooling (DCD, DScanner, serve-d, etc.) would need to be updated to support it.

You can actually have multiple modules on run.dlang.io, using the following syntax:

--- lib.d
module lib;

int fun() { return 42; }

--- app.d
module app;

import lib;

void main()
{
    assert(fun() == 42);
}

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.