`restricted` member variables

[bauss]

On Tuesday, 21 June 2022 at 10:32:10 UTC, The Zealot wrote:
> On Tuesday, 21 June 2022 at 01:18:38 UTC, forkit wrote:
>> On Monday, 20 June 2022 at 11:04:16 UTC, Mike Parker wrote:
>>> [...]
>>
>> I don't want to rehash it either, so I'll limit this to one 
>> post in this thread.
>>
>> [...]
>
> you can already express the intent more clearly by putting the 
> class in either a separate module, or function scope.
> we _do_ understand your point, we disagree on it's usefulness 
> and the complexity it adds to the language.

What complexity are you talking about? It'll hardly make a 
difference, if anything adds complexity to the language then it's 
stuff like dip1000, importC and the whole attribute hell D has 
bestowed upon itself etc. not anything related to "class private".

If you think "class private" is too complex, then arguably 
programming isn't for you.

If you think it adds complexity to the language and/or compiler, 
then arguably you don't understand how a programming language is 
developed.

There's literally nothing complex about something being private 
to a class. It's a concept that has existed before D was even a 
language. Arguably module private is more complex.

Not to mention some of those things were just added over night 
and/or don't work as intended.

I'm not against module private, but it sure would be nice to have 
the opportunity to opt-out sometimes.

But that's besides the point of this discussion.

I do believe this whole thread wouldn't be necessary if class 
private really existed.

It will solve this issue and many more, it will hardly create any 
issues that people will not be able to overcome.

Every piece of code existing today will work the same way, the 
only difference will be in future apis.