Sealed classes - would you want them in D?

[Mike Parker]

On Friday, 11 May 2018 at 14:05:25 UTC, KingJoffrey wrote:

> private is not private at all in D, and because of this, 
> classes are fundamentally broken in D (by design apparently).
>
> Now.. I really do have better ways to spend my time. I've made 
> my point. Nobody who uses D seems to think in a similar way, 
> apparently, so I leave it at that.

Classes are *not* broken in D. The module is the lowest level of 
encapsulation and provides exactly what encapsulation is supposed 
to provide -- the ability to hide the implementation from the 
outside world so that it may be changed without breaking the API. 
Being able to access private class members in the same module 
does not break encapsulation. If you make a change to the class 
that breaks something in the module, you have access to the 
module to fix what is broken. It's no different than what happens 
when you break code in the class itself, e.g this:

```
module m;

class Foo {
    private int x;
}

void manipFoo(Foo f) { f.x += 1; }
```

is no different than this:

```
module m;

class Foo {
    private int x;

    void manip() { x += 1; }
}
```

In both case, a change to the name or type of x can break the 
local functions and, in both cases, the person changing x has 
access to the local functions to fix the breakage. I don't see 
how putting the function outside or inside the class declaration 
makes any difference.