how to make private class member private

[Nick Treleaven]

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.