Adding a new design constraint to D

[Mike Parker]

On Tuesday, 14 June 2022 at 12:57:57 UTC, bauss wrote:

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

Will you please stop insulting my intelligence? I understand what 
you are saying. I'm just asserting that it's wrong.

Bar has the *public* interface of Foo, true, but it does not have 
the private one. The private one is internal to Foo, so to get at 
it through an instance of Bar, then Bar either has to be in the 
same module as Foo, or you have to convert the instance to a Foo 
first.

This is core to D's implementation of classes. If you access the 
private members of a superclass through instances of its subclass 
in the way that your original example did, then you are opening 
yourself up to a potential future bug. So the compiler prevents 
you from doing it and requires you to explicitly do it through 
the instance.SuperClass.field syntax.

If that behavior were to change so that `instance.field` works in 
your example, then we'd be weakening the implementation, not 
strengthening it.