`restricted` member variables

[Paul Backus]

On Wednesday, 22 June 2022 at 23:31:28 UTC, user1234 wrote:
> to be fair, I think that, to any example presented here, the 
> answer will be "put the aggregate declaration in its own 
> module". But let's try something simple:
>
> ```d
> struct VLA {
> private:
>     void* ptr;
>     size_t length;
> public:
>     void setLength(size_t value);
> }
>
> struct Other {
>     VLA vla;
>     void imBad() {
>         length += 1; // now I may have faults or not when 
> reading the vla
>     }
> }
> ```
>
> It's about being strict with yourself. What if I'm not really 
> good, make stupid mistakes ? Now I have a security barrier, I 
> can use `private(this)`, the compiler helps me with an error.

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.

(Also, because VLA's invariant is memory-safety related, I would 
get an additional security barrier by making its private members 
into [`@system` variables][1]. So the extra protection provided 
by `private(this)` would only be relevant in `@system` or 
`@trusted` code--which can bypass access controls anyway.)

[1]: 
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1035.md