We need an internal keyword.

[12345swordy]

On Sunday, 21 October 2018 at 08:40:36 UTC, Laurent Tréguier 
wrote:
> 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.
>
> This is by design; the D way of dealing with this would be to 
> split the module into a package with multiple modules. The A 
> class would be in its own module, and use `package` where you 
> used `internal` so that other modules in the same package can 
> have access to it.
> Using a package.d package module 
> (https://dlang.org/spec/module.html#package-module), you can 
> still use the multiple modules just as if they were a single 
> module.
>
> Instead of a source tree like this:
>
> source
> |
> +-some
>   |
>   +-thing.d
>
> You'd end up with a source tree like this:
>
> source
> |
> +-some
>   |
>   +-thing
>     |
>     +-package.d
>     |
>     +-a.d
>     |
>     +-rest_of_the_stuff.d
>
> Where package.d publicly imports a.d and rest_of_the_stuff.d, 
> so `import some.thing` would still work.
I know what the current design is!! You have zero tools in 
regarding to allowing class to share certain variables but not 
others in the same module! Create a module for every class is 
taking all or nothing approach, when there is a reasonable middle 
ground.
Your package solution just make things more unnecessarily 
complicated then warranted