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

[KingJoffrey]

On Friday, 18 May 2018 at 22:10:51 UTC, Maurice Huuskes wrote:
>
> The only thing that's going to drive this discussion forward is 
> a few example use-cases (potentially borrowed from other 
> languages that ran into similar 'problems'). I am new to D 
> myself and how private works did surprise me but using the 
> module/package method seems elegant enough to me.

I'll be honest. If people in the D community need to be provided 
with 'use cases' whereby private should not morph in public, then 
ya' all have bigger problems than you realise ;-)

should immutable morph into mutable?
(cause that might be convenient on rare occasions)

should const just morph in non-constant
(cause that might be convenient on rare occasions)

should safe morph into unsafe
(cause that might be convenient on rare occasions)

so why should private morph into public?
(oh.. i know...cause that might be convenient on rare occasions)

it's a really odd design decision to relax that rule just for 
'private', and, it can have a really big impact on software 
quality (not to mention security).

it means, now you have to 'extra care'. cause the compiler won't 
tell you that you accidently accessed the private part - you'll 
have to work that out during your debugging sessions.

or, it means you have to find some hack to get around it.. (one 
class per module).

the option to stop private morphing into public, and the option 
to have compile time check of your semantics, is what the vast 
majority of programmers in the world already enjoy. Come on D. 
get with it!

But in any case, ya' all decided - cause D has no place in my 
development team until I can have more than one class in a 
module, and not be told that my private parts have to be public.

I believe this will continue to hold back D - until it empowers 
the programmer to have that control.