Adding a new design constraint to D

Max Samukha maxsamukha at gmail.com
Tue Jun 14 13:35:21 UTC 2022


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.

Despite the fact you can access Foo._c, you can't access it 
through a different path. This is how D's scopes work, and it 
makes sense. Consider:

```d
module a;

import b;

int x;

void foo()
{
     b.x = 1; // no access to x through b.x, even though the 
variable is visible in a.
}
```

```d
module b;

import a;

private alias x = a.x;
```

File systems work in the same way - you can't access a node via a 
path going through inaccessible nodes even if the target node is 
accessible from the current node via other paths.

That is, the module-level 'private' is still bad design, but it 
works consistently.


More information about the Digitalmars-d mailing list