`restricted` member variables

[The Zealot]

On Wednesday, 22 June 2022 at 23:31:28 UTC, user1234 wrote:
> On Wednesday, 22 June 2022 at 23:08:38 UTC, deadalnix wrote:
>> On Wednesday, 22 June 2022 at 21:30:07 UTC, forkit wrote:
>>> I refer maxhaton back to the seminal paper on the benefits of 
>>> abstract data types:
>>>
>>> Programming with abstract data types - Liskov and Zilles 1974
>>>
>>> https://dl.acm.org/doi/pdf/10.1145/942572.807045
>>
>> I wish you understood that every comment that you make where 
>> you fail to present any concrete instance of the problem 
>> caused weakens your case.
>>
>> Assuming the people you are talking to are not well versed in 
>> the concept of asbtract data types is somewhat amusing, but 
>> I'm afraid, also playing against your case.
>
> 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.


there's no practical difference to this:

```
struct VLA {
private:
     void* ptr;
     size_t length;
public:
     void setLength(size_t value);
     void imBad() {
         vla.length += 1; // now I may have faults or not when 
reading the vla
     }
}

struct Other {
     VLA vla;
     void breaktheworld() {vla.imBad();}
}

```

in both cases your function breaks any invariants VLA might have. 
The real question is, why is VLA declared in the module scope in 
the first place? This is a prime example of why _class private_ 
encourages bad code design.