Add struct/class-scope private members

[andrey-zherikov]

Something like C++ private where members are not accessible from outside of a class/struct even within the same file.
Current D's private allows accessing within the same module.

[Lyratelle]

As long as no "friends" are introduced along with that, I have no problem.

[quickfur]

Wouldn't mind to have this, but please don't get to the point friend becomes necessary. C++'s friend is pure evil.

[strawberry9]

If creating a class is 'creating a type', then C++'s friend is a neccesary feature for operator overloading, since operators are not part of that type.

It's not the fault of 'friend' that programmers can (and often will) do 'evil' things with it,

Evil things can be done with almost any feature in a language.

But it is hard to think of a class inside a D module 'as a type', when you cannot encapsulate that type to ensure other code in the module interacts with it in a manner that is consistent with interacting with a type.

To make it a proper type, D requires that you put it in its own module - one type per module.

That brings me to Andrei Alexandrescu's reasoning in DIP1005 - for 'Increasing Granularity of Modules'. Much of his reasoning could easily apply to class private.

https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1005.md

[adamdruppe]

I'd imagine like

private(this)
private(module) (the default)

or something and otherwise things stay the same would be easy enough to do.

[jtbx]

Doesn't protected already do this?

[adamdruppe]

protected can still be seen by child classes... and i think other things in the module too.

[quickfur]

Hmm, I thought protected can only be seen by child classes, but apparently other things in the module can see it too:

class B {
        protected int x;
}

class D : B {
        void func() { x++; } // this is expected
}

void bunk(B b) {
        b.x++; // this also passes, hmm
}

[strawberry9]

Well that too can be fixed:

module test;
@safe:

import std;

// Access modifiers are used to implement an important aspect of Object-Oriented Programming known as Data Hiding.
// Currently there is no ability for data hiding in a D module.
// By adding a (this) component to both 'private' and 'protected', data hiding in a D module now becomes possible.
// Below is a comparison of private vs private(this), and a comparison of protected vs protected(this).

// private vs private(this)
//-------------------------
// A private member of a type is exposed to all code in the module.
// A private(this) member of a type is only accessible in the containing type.

// protected vs protected(this)
//-------------------------
// A protected member of a base class is exposed to all code in the module.
// A protected(this) member of a base class is only accessible in the containing type
// and types derived from it.
// NOTE: Neither protected nor protected(this) would apply to structs, since structs cannot inherit.

class A
{
private(this) int x;
protected(this) int y;
}

class B : A
{

}

void main()
{
auto A = new A();
auto B = new B();

A.x = 10; // OK: Access to x is occuring through its containing type A.
A.y = 10; // OK: Access to y is occuring through its containing type A.

B.x = 10; // Error: Access to x is limited to containing type A only.
B.y = 10; // OK: Access to y is occuring through B, which is a derived type of A.

}

[Lyratelle]

On a thread in the D forum someone came up with a real usecase for class-private (class invariants), and it became more clear to me that together with module-private 'friends' are not really needed (because if you would need them, simply change the member to module-private and you can have the necessary access).
So I'm no more against class-private (or private(this) as suggested). Should be easy enough to implement.

[strawberry9]

Yes, sadly, the scary message that D would need a C++ like friend feature if it ever got private(this) was always a redherring argument againt private(this).

As in the example below (which I find disturbing), within the D module, C++ like friendship is already implicit, mutual, inherited and transitive - i.e the complete oppposite to what many programmers would expect. And there's nothing you the programmer can do about it.

private(this) would just give a level of control over module level visibility, back to the programmer, and will allow the compiler to enforce those design considerations.

It gives, while taking nothing away . That's the best kind of change ;-)

I'm very glad to see that OpenD was open to this.

However, I'd prefer to not have to always use a compile time argument to enable this feature. I really don't see the value in this requirement.

Better to enable it by default so source code that uses it can be exchanged more easily.

module test;
@safe:

import std;

class YourClass
{
public:
this() { topSecret = 0; }
void printMember() { writeln(topSecret); }

private:
int topSecret;
}

class YourOtherClass
{
public:
void change(YourClass yc, int x) { yc.topSecret = x; }
}

class YourDerivedClass: YourClass
{
public:
void set_topSecret(int x) { topSecret = x; }
void get_topSecret() { writeln(topSecret); }
}

void main()
{
YourClass yc1 = new YourClass();
YourOtherClass yoc1 = new YourOtherClass();
YourDerivedClass ydc1 = new YourDerivedClass();

yc1.printMember(); // 0

yoc1.change(yc1, 5);
yc1.printMember(); // 5

ydc1.set_topSecret(3);
ydc1.get_topSecret(); // 3

}

[adamdruppe]

oh oops i thought it was enabled by default, i missed that spot of the thing. i'll fix that in the next push.

[adamdruppe]

It should be merged in the latest master fyi