`restricted` member variables

[deadalnix]

On Wednesday, 22 June 2022 at 23:31:28 UTC, user1234 wrote:
> ```d
> struct VLA {
> private:
>     void* ptr;
>     size_t length;
> public:
>     void setLength(size_t value);
> }
>
> struct Other {
>     VLA vla;
>     void imBad() {
>         vla.length += 1; // now I may have faults or not when 
> reading the vla
>     }
> }
> ```
>

This is a good starting point.

Yes, Other will be able to manipulate VLA's innard in this 
exemple. Now there are two questions that immediately come to 
mind:
1/ Should it be able to? From this limited example, it's hard to 
tell, but there is no need to be pedantic so we'll assume that 
yes it does. You'll note that this is not obvious per so, Other 
might be a view on the VLA for instance.
2/ If 1/ is true, then do they really belong in the same module?

I think 2/ is the question that is being skipped there, because 
the very characteristic of a module is to be the place where all 
the element it contains are implemented. If it is capital that 
Other is not exposed to the innard of VLA, then is it hard to 
defend that implementing them both together in the same place is 
the right design choice.

> 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.

While I do indeed believe that it is good to be strict with 
yourself, I do not believe the arguments extends to private(this) 
based on the sample provided. In fact, I had to correct said 
sample to add an explicit reference to `vla.length` instead of 
just `length`. The compiler is already helping you avoiding 
accessing the innard of another object by mistake, it has to be 
explicit. The proof is in the pudding, the code had to be 
modified for it to be explicit.