On Tuesday, 13 March 2018 at 05:11:48 UTC, psychoticRabbit wrote:
If you have access to the module source, you have access to
the source of types inside it. Making the module the lowest
level of encapsulation makes sense from that perspective.
There are two problems I see:
1st - D has broken the concept of class encapsulation, simply
for convenience at the module level. Not good in my opinion.
It's a language design decision as to whether a particular
feature is worth supporting. I would like this feature too
though. I'm not sure how much compiler complexity would be added
by having another visibility modifier.
I'm surprised how many people here ignore the advantage of being
able to modify your class/struct fields without the chance of
breaking template code that might not even be instantiated by a
unit test. (And no, the answer to this isn't fix your tests,
because if that's your attitude, why bother with static typing,
just use duck typing, the unit tests will catch any bugs). In
theory this and other generic unit test issues could be
comprehensively solved by having a Rust-like traits feature.
2nd - C++/C#/Java programmers will come to D, use the same
syntax, but get very different semantics. Not good in my
opinion. (i.e. I only realised private was not private, by
accident).
D has made many good design decisions. I do not see this as one
of them.
+1, D should have used a different keyword, such as `module`. It
is a classic source of confusion for programmers familiar with
many statically typed languages, and it comes up regularly here.
It is a syntax issue, semantically the feature is better than
just having true private.
