Sealed classes - would you want them in D?

[KingJoffrey]

On Tuesday, 15 May 2018 at 05:59:44 UTC, Mike Parker wrote:
>
> Jonathan's right. We're just not going to agree on this.

The purpose of discussion is not necessarly to get one side to 
agree with other side.

> You can keep your grouping and get your strict encapsulation 
> like so:
>
> // foo/bar/baz/package.d
> module foo.bar.baz;
> public import
>     foo.bar.baz.a,
>     foo.bar.baz.b,
>     foo.bar.baz.c,
>     foo.bar.baz.funcs;
>
> The client need neither know nor care that everything is in 
> separate modules and you get your strict encapsulation. You can 
> still share items between modules via package protection, and 
> within specific package hierarchies via package(packageName). 
> And even better, you now have less code per module to reason 
> about (re: one of your earlier arguments against the current 
> behavior).

Fine. If I take your solution above, and ensure that every class, 
goes into it's own module, and that a module containing a class, 
contains nothing other than a single class (i.e no free 
functions), then sure, I end up where I am now, with C++/Java/C# 
- i.e a good place, where I feel comfortable. My declared 
interface is respected.

Why do I need D then? i.e. under what circumstances, would I want 
to put something extra into the module, so that it can abuse the 
declared interface of my class?

Can you give me some examples?