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

[Arafel]

On 27/4/24 15:10, Dukc wrote:
> I need to stress though, that you need to approach this subject with 
> utmost diplomacy and humblety. Class-level |private| has been the very 
> subject of more than one flame war in these forums. You will quickly 
> become shunned if you're seen as instigating another one. The 
> disclaimers you included at beginning of your post hint that you're 
> already aware of that.

I have to say I have been surprised at how strongly some people react. I 
started by saying that I think it's a minor issue, has a workaround, and 
the workaround doesn't even feel too unusual to me. In short: I don't 
think it's worth raising a fuss, it's just one of those odd quirks that 
you learn to live with.

Still, I think it makes sense as a feature, and, honestly, I see it as a 
low-hanging fruit: it's an addition to the language, fully opt-in, it 
doesn't interact with pretty much anything else*, and has an already 
working implementation with even some real-life exposure to find out the 
rough edges.

So given that there are few drawbacks (I would dare say none beyond a 
very much hypothetical "complexity" in the language), and acknowledged, 
even if minor, benefits, the question for me becomes: "why not?".

"Because that's how things are" is something I can happily accept, as I 
have been doing so far, but not agree with.

*: Assuming you define it as: "for `private(this)` members or methods, 
code outside the class (or eventually struct) behaves as if it were in a 
different module".