`restricted` member variables

[forkit]

On Wednesday, 22 June 2022 at 23:55:17 UTC, Paul Backus wrote:
>
> As you point out, you can already create such a security 
> barrier by splitting the code into separate modules.
>
> Nobody denies that the ability to create more fine-grained 
> security barriers has *some* utility in *some* situations. The 
> question is, does it provide *enough* utility in *enough* 
> situations to justify the addition of a new language feature?
>
> Personally, I like to write small modules, and would probably 
> put my VLA definition in its own module even if `private(this)` 
> were available. So `private(this)` would not actually bring me 
> any benefit in this situation.

Is it a security barrier?

I think of it more as an encapsulation barrier.

Like my wall around my house. It's only secure as long as nobody 
tries to knock it down.

Also, let's not forget about 'choice' here.

the use of private(this) is the choice of the designer. always!

if it benefits you, choose to use it.

if it doesn't, don't use it.

but currently, D provides NO CHOICE, other than to put every 
class in its own module, so that it can be treated as a 'defacto' 
abstract data type.

Walter is already on the record as saying this is not an 
appropriate contraint to put on programmers.