Code That Says Exactly What It Means

[jmh530]

On Tuesday, 28 October 2025 at 22:36:58 UTC, Lance Bachmeier 
wrote:
> [snip]
>
> Over the years this has come up many times. Can you provide an 
> example showing the value of doing that? I understand that 
> maybe that's your preference for whatever valid reason, but 
> I've never seen anyone give an example where it's actually a 
> constraint.
>
> If you want to push on this, that's where you should start. 
> Because every previous such proposal I've seen has died, as the 
> people requesting it keep arguing from authority that it's the 
> correct way to do things, rather than demonstrating the benefit 
> of a major change to the language.

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.