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.
