`restricted` member variables

[Mike Parker]

On Thursday, 23 June 2022 at 10:36:02 UTC, forkit wrote:
> On Thursday, 23 June 2022 at 10:34:50 UTC, Alexandru Ermicioi 
> wrote:
>> On Thursday, 23 June 2022 at 10:16:42 UTC, forkit wrote:
>>>
>>> Coding style?
>>>
>>> Ummm .. no.
>>>
>>> Why is it, that some people ***still*** don't get it.
>>
>> I think that all people here get it. They don't agree on 
>> making an elephant out of mosquito.
>
> But it is an elehpant, not a mosquito.
>
> That's the point I've been trying to make - which it seems, is 
> still not getting across to some.

Seriously, everyone here gets it. If they didn't before, they 
surely do by now. It's just that we disagree with you. That's it. 
And so far, you still haven't shown any real problem that 
`private(this)` solves.

Violation of encapsulation at the class boundary within the 
module *in D* is a conceptual problem. That's not true in other 
languages, but it's true here. That's because for the public API, 
where encapsulation actually matters in D, it happens at the 
module level.

I could go all "I can't understand why you don't get it", but I 
haven't gone there and I'm not going to. Fundamentally, you're 
refusing to accept that it isn't an elephant after all. And 
that's fine.

That's your prerogative. But please, just accept that we do 
understand you points and simply disagree with you. Repeating 
them endlessly isn't convincing anyone. If you want to convince 
someone, show us a real problem that `private(this)` solves *in 
D*.

And good luck! I'll keep an eye out for the post that gets there.