`restricted` member variables

[forkit]

On Thursday, 23 June 2022 at 00:05:24 UTC, Paul Backus wrote:
>

Also the argument from Mike, against this idea, was that you have 
access to the module. So why protect yourself from what you have 
access to.

I can use a similar arguement:

by having access to the module, you have the capacity to 'grant' 
yourself access, or not.

if you grant yourself access to use the internals of your type 
outside of that type (but within the same module), you're not 
protected from accidents.

if you don't grant yourself access, you are protected from 
accidents.

the argument that you have access to the module, and accidents 
won't happen, or 'just don't do it', is nonsensical.

any programmer knows, that accidents happen - sometimes far too 
often.

but you have access to the module, so you decide whether you want 
to be protected from accidents or not.

currently, there is one, and only one way to protect yourself in 
D.

that's to put every class in its own module.

even closely related classes -> each into their own module.

every abstract data type you define -> into its own module.

it's just a crazy imposition. no other language I've ever used 
imposes this onto me.