`restricted` member variables

[forkit]

On Thursday, 23 June 2022 at 09:49:25 UTC, Dom Disc wrote:
>
> ...
> No, but this whole discussion is only about coding style 
> (putting each class in its own module or not). And from style 
> guide perspective having more options is always bad. It reduces 
> the readability.

Coding style?

Ummm .. no.

Why is it, that some people ***still*** don't get it.

It's about being able to declare, as strongly typed, abstract 
data object, that is responsible for declaring and maintaining 
its own invariants, and where the compiler can enforce those 
invariants.

It is perhaps, the single most important concept for good, 
scalable, software engineering.

Sure, D has a 'workaround' where you can 'simulate' this. But 
it's deficient. As soon as you add any code whatsover to the 
module, the simulation dissolves.

The only solution to not having a strongly typed abstract data 
object, is to have one.

It makes software engineering better, not worse.

But more importantly, you get to decide whether to use it or not.

Like it's completely up to you. You don't like it? Don't use it. 
Simple.

If it's the thing you've waiting for, for years, then woohoo!

At least someone had the balls (or otherwise), to take this to 
the next level and actually try putting it in as a preview, so 
people can try it.

Again, totally up to you to try it or not.

want to try it: '-preview=privateThis'

don't want to try it: ''

It's up to **you**

C has it's million dollar mistake.

I think missing this important feature was D's million 'user' 
mistake (a million missing users because of it).