Adding a new design constraint to D

[bauss]

On Tuesday, 14 June 2022 at 12:47:31 UTC, Mike Parker wrote:
> On Tuesday, 14 June 2022 at 12:39:33 UTC, bauss wrote:
>
>>
>> That shouldn't matter, if you have access to screw up with _c, 
>> then you have access to the module and thus it is your own 
>> responsibility to make sure you don't create subtle bugs.
>>
>> Isn't that the whole point behind module-level privacy?
>>
>> You have access to the module, thus you have control over the 
>> module. It shouldn't matter how you get into the module etc. 
>> since you're the owner of the module, then you're the one 
>> responsible for it.
>>
>> You see, your argument against all of this is the exact 
>> argument that is for type-level privacy, since you wouldn't be 
>> able to create a subtle bug like this and you wouldn't be able 
>> to cast to the parent type in the module and hack your way 
>> around that way either.
>>
>> It solves both problems.
>
>
> No, that doesn't hold in your example because Bar was *not* in 
> the same module. Going through .Foo gives you access to Foo's 
> private parts because it *is* in the same module.
>
> If you want to argue that you should be able to access child._c 
> when both Bar and Foo are in the same module, well, you can:
>
> ```d
> class Foo {
>     private int _c;
> }
>
> class Bar : Foo {
> }
>
> void baz(Bar child) {
>     child._c = 10;
> }
>
> void main()
> {
>     Bar b = new Bar;
>     baz(b);
>     writeln(b._c);
> }
> ```

Sure Bar wasn't in the same module, but Foo is and Bar inherits 
from Foo, thus Bar is Foo and Foo has access to _c in Foo's 
module and thus Bar should have access to Foo's private members 
in Foo's module, because Bar is Foo.

It's really not that difficult to grasp such a concept.

Here it is illustrated with my terrible graphic skills:

https://i.postimg.cc/0Q3XSN47/illustrated.png