how to make private class member private

[aliak]

On Tuesday, 13 March 2018 at 06:58:08 UTC, psychoticRabbit wrote:
> On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote:
>>
>> The same applies here. Encapsulation simply isn't broken by 
>> this feature.
>
> What you're saying, is in D, class encapsulation is really 
> 'module' encapsulation.
>
> I get it. Fine. It's an intersting design decision.
>
> But, in doing that, D has shifted the boundary of class 
> encapsulation, to a boundary that is outside the class.
>
> To me, that sounds like D has broken class encapsulation. I 
> don't know how else one could describe it.
>
> I continue to think, that class encapsulation is sacred, a well 
> defined, well understood, concept that has been around for a 
> very long time.
>
> private could have still meant private, and surely someone 
> could have come up with a different access modifier to mean 
> 'private at module level'.
>
> Was that too hard the language designers?
>
> Was it not hard, but just to complex to implement?
>
> I don't get it.

I agree that class encapsulation is broken, well, not broken but 
just not a thing really. Don't think it's a bad thing though. 
Case in point, swift had private as file level access, swift 3 
they introduced fileprivate [0] to do that instead and had 
private be scope level (which includes class level and is what 
you're referring to private being).

Swift 4 they reverted it .... kinda [1]

It was too inconvenient to not allow access to private members 
within a file in a language that allows extensions (think ufcs). 
So they compromised a bit here and went for decleration level 
which makes sense within their extension semantics. This would 
not work for D thought because ufcs is not really a type 
extension (i.e. not part of a type's typeinfo)

So now the difference is that private can be used in a file but 
only in a declaration and fileprivate can be used anywhere in a 
file. So they allow class encapsulation but at a file level. It's 
an interesting approach and quite neat.

Rust is also the same as D I believe. Module is the unit of 
encapsulation.

I wouldn't want private to change it's meaning quite frankly in 
the module system. I would not mind more control within a module 
though because, well, encapsulation. A Rust-ish approach were you 
can define a path [2] might allow for a lot more freedom but I'm 
not sure how well that would work with D.

Cheers

[0] 
https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md
[1] 
https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
[2] 
https://doc.rust-lang.org/beta/reference/visibility-and-privacy.html