Sealed classes - would you want them in D? (v2)

[bachmeier]

On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote:

> This discussion (at least my reason for being involved in it) 
> is about breaking this idiotic (in my opinion) concept that D 
> enforces on 'everyone' - i.e the one class per module, or 
> everything is public, and you have no say in it.
>
> I don't necessarily object to the freedom the D module provides 
> (i.e to bypass your interfaces, even accidently). What I object 
> to is the 'i.e the one class per module, or everything is 
> public, and you have no say in it.'

I'm not saying I oppose making this change, but "evolution of the 
language" takes the form of adding features but never eliminating 
any. If I see

class A {
    private int x;
    private(this) int y;
}

it kind of makes my head hurt, and I've been using D for five 
years. The justification I've seen for complications like private 
vs public is that it's necessary for large programs. There's 
something wrong if a single module is considered large.

Unlike most of the people that post here, I work with beginning 
programmers. In almost all cases, decisions are made on the basis 
of appeal to 20-year C++ veterans, but at least I can say I 
raised the issue.