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

[NotYouAgain]

On Monday, 29 April 2024 at 13:39:17 UTC, Basile B. wrote:
> ..
> ..
> Personally I casually use FPC, which has `strict private` (i.e 
> `private(this)`) and `strict protected` (i.e `protected(this)`. 
> I dont find them essential but as a matter of discpline I have 
> used them a couple of time and found them to be useful, in 
> certain cases. For example presentation and logic implemented 
> in the same module, but be sure that the presentation will only 
> use the getters/setters of the logic and not the fields.

The source of all this, can be trace back to the D designer who 
decided to change the "right and obvious" meaning of private.

That was a mistake. It's not the the moduleprivate is wrong, that 
certainly has a place, but changing the meaning of private, was a 
mistake that D has to live with.

As Chris Lattner (of Apple) said (in their discussions on fixing 
the exact same problem they had in Swift):

(1) "We keep public and private meaning the “right” and “obvious” 
things."

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013261.html

It's time (a decade overdue actaully) for the D community to have 
this discussion.

Swift was already used widely when they made this change 8 years 
ago.

D is not in even widespread use today.

D could make the same change, and restore private to what 
everyone knows it to mean, and use moduleprivate or fileprivate 
as meaning private to this module.

Yes, I know the opposition to this idea. I do not need to here 
from them again. I'd rather here from those who support change, 
not those who are totally against it (as their views are already 
known).

That was the whole point of presenting this idea in the DIP ideas 
group, instead of the General group, where everyone piles onto 
you if you raise this idea.