Adding a new design constraint to D

bauss jj_1337 at live.dk
Tue Jun 14 12:39:33 UTC 2022


On Tuesday, 14 June 2022 at 12:33:53 UTC, Mike Parker wrote:
>
> So then what do you do when your direct access to `child._c` 
> suddenly starts causing a subtle bug because someone added 
> later added a `_c` member to the public interface of `Bar`? 
> Private members are not inherited and do not impact the public 
> interface.

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.


More information about the Digitalmars-d mailing list