`restricted` member variables

[Dom Disc]

On Thursday, 23 June 2022 at 03:55:00 UTC, forkit wrote:
> On Thursday, 23 June 2022 at 01:27:23 UTC, Mike Parker wrote:
> Well, the 'invariant' statement in D, is interesting, but no 
> replacement for strong typing.

If you accept that one module should only contain one class and 
it's friends, then it is strong typed. Hey, even the OS support 
its encapsulation: you can make the file read only. What better 
encapsulation do you want?

> I cannot put "wtf" into an int.

Yes. Because from user perspective it is encapsulated. But if you 
own the module where int is implemented, of course you can add 
"wtf" there!

If you want your class to be encapsulated the same way, put it in 
its own module and make it read only. You can be sure nobody can 
add "wtf" to your class, just like with int.

> I no longer have to put that type in its own module

But this is just coding style.

And here you see the cost of private(this). As of now, everybody 
reading a D source file can be sure everything in a module 
belongs together. Because a special coding style is enforced on 
the developers by the language. With private(this) that 
assumption no longer holds. You can conflate everything in one 
file. Just because now you have that option.

Can you see that it has some negative impact? It's benefit has to 
outweight that impact, or it is not worth adding it. And many 
people in this forum think it doesn't. That is why they insist on 
you presenting evidence of the benefit.

Coding style guides are good. It makes a language much more 
readable if everybody is enforced to do one thing always the same 
way. Of course they reduce your freedom. If you were a poet, that 
would be really bad. But as a programmer do you need that 
freedom? Isn't it sufficient, that there *is* one way to do 
something?