Private this

[adamdruppe]

borrowed from upstream lol

[fqbqrr9]

borrowed from upstream lol

I like it.

[ssvb]

Wow, thanks for picking this up. This functionality is very useful for the people interested in OOP. Though the D's private keyword is going to still remain confusing for the newcomers arriving from C++.

[adamdruppe]

It is tempting to allow private(this) and private(module) to be more specific but really im happy with D's private the way it is most the time so i don't wanna complicate too much.

[ssvb]

Yes, I don't want to break compatibility with D either and the current D-style private is fine the way it is.

But now I wonder if it would make sense to treat the private keyword as private(this) if the source file has no module name explicitly specified via the module keyword? This way it would behave like C++ when rapidly implementing some proof-of-concept object oriented prototype code in a single file. Restricting access to class members and methods allows to experiment with it and make up one's mind about what should and what shouldn't be a part of the public interface of this class. And after the prototype code works as expected, in can be cleaned up and converted into a proper module.

I mean, at the prototype stage it can be a single file:

import std.stdio;

class A {
  private int x;
  this(int _x) { x = _x; }
}

void main() {
  auto a = new A(123);
  writeln(a.x); // D allows this, but maybe OpenD can complain here?
}

After splitting the prototype code into multiple files and having it as a proper module:

module aclass;

class A {
  private int x;
  this(int _x) { x = _x; }
}

import aclass;
import std.stdio;

void main() {
  auto a = new A(123);
  writeln(a.x); // Both D and OpenD complain here
}

Is this too confusing/complicated?

[adamdruppe]

eh i think that's a bit complicated to explain to people (and my advice is often to always put the module declaration in there anyway...).