`restricted` member variables

[Ola Fosheim Grøstad]

On Wednesday, 22 June 2022 at 11:36:52 UTC, forkit wrote:
> Of course, this butchering does have an effect on OOP in D. But 
> that's not the main point here.
>
> In fact, you are always using abstract data types, and 
> benefitting from them, regardless of what 'paradigm' you're 
> using.

Yes, yes, yes, but many D programmers don't have formal training 
so they are going by what they read on blogs or their own 
experience.

It should be obvious to anyone that if D's strength is to go from 
prototyping to shippable products then solid support for 
evolution is needed. Fine grained encapsulation is absolutely an 
advantage. That's 100% undeniable. Especially in system level 
programming.

However, if I were to rank what should be focused on, then 
changing/adding to encapsulation would be at spot 20 or so…

Currently the big issue for D is *not loosing focus* and complete 
what has been started on:

1. competitive memory management
2. @safe and @trusted
3. completing existing features
4. fixing error handling
5. fixing contracts

When all that is done… by all means, look at encapsulation, 
syntax, etc.

But I would predict that the end result, after everyone has 
added/changed their pet peeve, would be something that would not 
be D2, it would be D3.

So the best option is to either make do with naming-conventions 
to get ad-hoc class-privacy or implement it as a fork.

If you want to do this in a fork then I'll try to help you with 
locating the spots that need modification. If you complete this 
on a fork, I'll help you write the DIP for it.