On Sunday, 21 October 2018 at 21:48:22 UTC, Laurent Tréguier wrote:
> On Sunday, 21 October 2018 at 17:09:05 UTC, 12345swordy wrote:
>> [...]
>
> It's not "my" solution. It's D's solution. I perfectly understand why you'd want this and I would probably make use of a private/internal difference myself if it was available.
>
> If you already know about this solution however, I don't even know why you're starting this thread; since changing the behavior of private would be a major language change breaking tons of existing codebases, plus it would require adding yet another keyword.
>
> Given that this conversation has happened before and things haven't changed, I'm very doubtful that it could happen at any point in time, sadly.

If the cost out way the benefits then I simply introduce the "strict" keyword to avoid code breakage, or introduce the optional module scoping.

-Alex

On 10/20/18 11:17 PM, 12345swordy wrote:
> So that classes can share some of their variables but not others in a module.
> 
> IE.
> 
> class A
> {
> internal int A; //This is shared in the module
> private int B; // But not this.
> }
> 
> No need to reintroduce the "Friend" feature from cpp.

I've always felt the same.

I certainly don't intend this as a way to say "just accept it and forget about it", but FWIW, I've learned to live with it: I just regard accessing such privates from outside their class/struct to be bad style. I mean, I agree it's not ideal, but at least it doesn't prevent me from getting things done. Again, FWIW.

That said though, it *can* sometimes be helpful for tests and debugging to be able to reach into a class/struct and muck about with the privates. (tee hee). But FWIW, I do agree. If D were my own language, I'd probably have done it a little differently: I would've taken the current "private" behavior and called it something like "module", and made "private" behave the way it does in other languages.

On Sunday, 21 October 2018 at 23:50:57 UTC, 12345swordy wrote:
> On Sunday, 21 October 2018 at 21:48:22 UTC, Laurent Tréguier wrote:
>> On Sunday, 21 October 2018 at 17:09:05 UTC, 12345swordy wrote:
>>> [...]
>>
>> It's not "my" solution. It's D's solution. I perfectly understand why you'd want this and I would probably make use of a private/internal difference myself if it was available.
>>
>> If you already know about this solution however, I don't even know why you're starting this thread; since changing the behavior of private would be a major language change breaking tons of existing codebases, plus it would require adding yet another keyword.
>>
>> Given that this conversation has happened before and things haven't changed, I'm very doubtful that it could happen at any point in time, sadly.
>
> If the cost out way the benefits then I simply introduce the "strict" keyword to avoid code breakage, or introduce the optional module scoping.
>
> -Alex

Technically, introducing any new keyword is also a potentially code breaking change. Any symbol named "strict" would have to be changed. This is why I'm doubtful that such a change would be accepted.

On Sunday, 21 October 2018 at 23:50:57 UTC, 12345swordy wrote:
> If the cost out way the benefits then I simply introduce the "strict" keyword to avoid code breakage, or introduce the optional module scoping.
>
> -Alex

Looking at the dlang.org page about visibility attributes, the `package` keyword can have an argument specifying which package has access to the symbol.
What if `private` could have an argument dictating which other symbol could have access to that private symbol ?
Setting this argument to the private symbol's own class would effectively make it strictly private. This wouldn't require a new keyword, and that syntax is not valid D code so it wouldn't break any existing code.
Though it would look a bit weird, and it would also basically introduce a sort of "friend" feature.

I don't know, that was just a random thought that crossed my mind just now.

On Sunday, 21 October 2018 at 03:17:23 UTC, 12345swordy wrote:
> So that classes can share some of their variables but not others in a module.
>
> IE.
>
> class A
> {
> internal int A; //This is shared in the module
> private int B; // But not this.
> }
>
> No need to reintroduce the "Friend" feature from cpp.

As just said by others, if you need it probably your module is too big and you have to split.

Moreover: you're the author of the module so you're supposed to know how it works and which members you should call or not. Anyway since they're private you can name them in particular way to remember yourself not to use them eg: int internal_A;

Andrea

On Monday, 22 October 2018 at 08:25:17 UTC, Andrea Fontana wrote:
> Moreover: you're the author of the module so you're supposed to know how it works and which members you should call or not.

- team
- maintainer of a module written by someone that works elsewhere now.

that's two cases where strict privacy can be optionally a thing avoiding wrong usage of private members within the scope of a module.

On Monday, October 22, 2018 2:30:21 AM MDT Basile B. via Digitalmars-d wrote:
> On Monday, 22 October 2018 at 08:25:17 UTC, Andrea Fontana wrote:
> > Moreover: you're the author of the module so you're supposed to know how it works and which members you should call or not.
>
> - team
> - maintainer of a module written by someone that works elsewhere
> now.
>
> that's two cases where strict privacy can be optionally a thing avoiding wrong usage of private members within the scope of a module.

Part of the point is that if the module is large enough that the folks working on the code can't actually keep track of what's in it, then it's too large, and as such, if you need to protect your class or struct members from the rest of the module, then it really should be in a separate module for the code to be properly maintainable anyway. Yes, having multiple people involved makes the problem worse (especially when some of them join the team later), but it doesn't fundamentally change the issue. If it changes anything, it simply makes the argument stronger for preferring smaller modules so that they're easier to digest.

Personally, I've found that larger modules have worked just fine for me without having to worry about these sort of encapsulation issues. It simply isn't a problem, and I don't recall ever seeing a bug because of it. But anyone who's worried about it always has the option of simply going for smaller modules, and the encapsulation problem is already solved without making the language any more complicated. Plenty of folks already think that it's best practice te prefer relatively small modules anyway, and if you need a way to protect your private member variables from the module when the module isn't large, then you're definitely doing something wrong.

Given the D philosophy that the module is the primary unit of encapsulation and that you should at least roughly understand the entire module when working on it (or it's almost certainly too large), having an access level to protect member variables from the rest of the module simply makes no sense. Anyone who feels the need for such an access level think about what they're doing with their code and why they feel the need for it - whether it's simply because they're used to it from other languages, or because they're organizing their code in a manner which is detrimental to maintainability.

- Jonathan M Davis

On Monday, 22 October 2018 at 11:06:42 UTC, Jonathan M Davis wrote:
> On Monday, October 22, 2018 2:30:21 AM MDT Basile B. via Digitalmars-d wrote:
>> On Monday, 22 October 2018 at 08:25:17 UTC, Andrea Fontana wrote:
>> > Moreover: you're the author of the module so you're supposed to know how it works and which members you should call or not.
>>
>> - team
>> - maintainer of a module written by someone that works elsewhere
>> now.
>>
>> that's two cases where strict privacy can be optionally a thing avoiding wrong usage of private members within the scope of a module.
>
> Part of the point is that if the module is large enough that the folks working on the code can't actually keep track of what's in it, then it's too large, and as such, if you need to protect your class or struct members from the rest of the module, then it really should be in a separate module for the code to be properly maintainable anyway. Yes, having multiple people involved makes the problem worse (especially when some of them join the team later), but it doesn't fundamentally change the issue. If it changes anything, it simply makes the argument stronger for preferring smaller modules so that they're easier to digest.
>
> Personally, I've found that larger modules have worked just fine for me without having to worry about these sort of encapsulation issues. It simply isn't a problem, and I don't recall ever seeing a bug because of it. But anyone who's worried about it always has the option of simply going for smaller modules, and the encapsulation problem is already solved without making the language any more complicated. Plenty of folks already think that it's best practice te prefer relatively small modules anyway, and if you need a way to protect your private member variables from the module when the module isn't large, then you're definitely doing something wrong.
>
> Given the D philosophy that the module is the primary unit of encapsulation and that you should at least roughly understand the entire module when working on it (or it's almost certainly too large), having an access level to protect member variables from the rest of the module simply makes no sense. Anyone who feels the need for such an access level think about what they're doing with their code and why they feel the need for it - whether it's simply because they're used to it from other languages, or because they're organizing their code in a manner which is detrimental to maintainability.
>
> - Jonathan M Davis

Here is the intial dip draft: https://github.com/12345swordy/DIPs/tree/Encapsulation
If Walter Bright insist that the module is the unit of encapsulation then I propose we get rid of the "one module per file" restriction, by introducing sub modules.

-Alex