Extending D's support for object-oriented design with private(this)

[NotYouAgain]

On Saturday, 27 April 2024 at 01:41:54 UTC, Jonathan M Davis 
wrote:
>
> Arguably, if someone feels the need for something like 
> private(this), they're either doing something wrong, or they 
> want it simply on the principle that types should be able to 
> prevent all code that's external to them from accessing their 
> private data. It really isn't an issue in practice, and if you 
> really want to ensure that code can't access a type's private 
> data, the workaround is simple.
>

I'm not doing anything wrong!

I'm declaring a user-defined class type, and I want it to have 
private members, that I don't want to be accessed outside of the 
scope in which the class is being defined.

How am I doing anything wrong here?

The class type can already prevent access to its private members 
- but only to code outside the module. Are you saying this isn't 
necessary? Just make it all public and no problems will arise? 
Well, problems WILL arise. Just as problems 'can' arise with code 
inside the module.

I'm trying to provide a strong type here, but D won't let me. It 
has no mechanism to do that, as it doesn't consider a class type 
to be a true type (but nontheless, declares itself to support OO 
programming).

To code 'outside' the module, I can present the class as a true 
type - 'private'.

To code 'inside' the module, I cannot. It simply cannot be done. 
Inside the module, 'private' means nothing.

The only solution you and others put forward, in order to ensure 
private really is private in a module, is to ensure no other code 
is in the module.

Really?!? You may as well tell me to f$$$ off. Cause they both 
mean the same to me.

Also, I'm not insisting that private be changed, only that 
private(this) be added.

*Both* have their use. In OpenD, **I** can choose between private 
and private(this). That's exactly what I would expect from any 
language I chose to program in.

Why would anyone *insist* on preventing me from doing that?

You cannot reason around a class type in D, when other code is in 
the module.
You have to take all that other code into account - and there 
lies the problem. The compiler will never know, and a code 
revievwer will have to review all code in the module, just to 
understand the intent in the desing of the class.. if they're 
lucky.

 From the code in the class-type, I should be able to extract a 
proof or its correct usage.

In D, a proof is not possible when there is other code in the 
module.

And 'the workaround' is not simple!

I want to make it simple, by integrating into D, an optional 
feature (that already exists in OpenD, Swift, C++, Java, C# 
......), so that the programmer can make the class contain 
'proof-carrying code' - code that explicately declares how this 
type can be used.

private(this) is what would make it simple. My motivations could 
not be clearer.