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

[NotYouAgain]

On Thursday, 25 April 2024 at 12:55:33 UTC, Lance Bachmeier wrote:
>
> This introduces a more restricted version of private. 
> Overloading `private` to give it a second meaning is going to 
> cause confusion for new users and really anyone that doesn't 
> use D's OOP all the time. I recommend using something like 
> `hidden` or `strongprivate`.

Yes, private(this) is more restricted, only in that it applies 
concept of private to the type - which is what the vast majority 
of class-oriented oo programmers would expect.

And being able to 'explicetly' ensapsulate a member to the type 
itself, is a no-brainer to oop programmers. But they can't do 
that in D.

In an ideal world, D would have done what Swift did - and have 
'private' mean what most oop's would expect it to mean (that is, 
restricted to the enclosing declaration), and 'file-private' to 
mean what private means in D (that is, private to the module 
file).

But its rarely and ideal world.

A breaking change to fix this would *never* be accepted, 
*understandably*.

this(this) is an already available construct in D.

private(this) seems the best way to proceed I believe, since it 
*does* need to have the word 'private' in it, which is what any 
oop would expect.

  - 'strongprivate' suggest nothing really.
  - 'hidden' lacks clarity of its meaning.
  - 'private(this)' - private to 'this' (ie. this type) .. seems 
to me, to bring sufficient clarity to the construct, especially 
since the notion of 'this' is already clear in D classes.

Therefore private(this) seems the most sensible way to implement 
this - at this stage, given the above points.