Adding a new design constraint to D

[Mike Parker]

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);
}
```