On Wednesday, April 24, 2024 11:53:18 PM MDT Richard (Rikki) Andrew Cattermole via dip.ideas wrote:
> Apart from literature review type content, there isn't much to discuss here. There is nothing to tune.
>
> I suggest you start work on a draft DIP and move to development unless Walter or Atila have strong opinions against it.

Well, Walter has consistently shot down requests for this kind of feature in the past (and there was a discussion in the newsgroup within just the past couple of months where it came up IIRC, and Walter shot it down then), so unless someone can come up with a really compelling reason why it's needed, it's going to be shot down. Unless something has changed quite recently, Walter's opinion on this has already been made quite clear, and it's been the same for years.

The normal answer is that if you really need the other code in the module to not have access to the class' members, then that class should just go in another module. In practice, the current situation rarely causes problems. It seems more to be something that annoys some folks on principle rather than being an actual technical issue. I would be shocked if this DIP went anywhere.

- Jonathan M Davis

On 26/04/2024 12:55 AM, Lance Bachmeier wrote:
> This introduces a more restricted version of private. Overloading `private` to give it a second meaning is going to cause confusion for new users and really anyone that doesn't use D's OOP all the time. I recommend using something like `hidden` or `strongprivate`.

Hidden is used as an attribute, defined as a UDA in ``core.attributes``. It is related to exportation, so that is already taken.

On Thursday, 25 April 2024 at 19:48:11 UTC, Jonathan M Davis wrote:
> On Wednesday, April 24, 2024 11:53:18 PM MDT Richard (Rikki) Andrew Cattermole via dip.ideas wrote:
>> Apart from literature review type content, there isn't much to discuss here. There is nothing to tune.
>>
>> I suggest you start work on a draft DIP and move to development unless Walter or Atila have strong opinions against it.
>
> Well, Walter has consistently shot down requests for this kind of feature in the past (and there was a discussion in the newsgroup within just the past couple of months where it came up IIRC, and Walter shot it down then), so unless someone can come up with a really compelling reason why it's needed, it's going to be shot down. Unless something has changed quite recently, Walter's opinion on this has already been made quite clear, and it's been the same for years.
>
> The normal answer is that if you really need the other code in the module to not have access to the class' members, then that class should just go in another module. In practice, the current situation rarely causes problems. It seems more to be something that annoys some folks on principle rather than being an actual technical issue. I would be shocked if this DIP went anywhere.
>
> - Jonathan M Davis

My understanding of the difference with this proposal is that it would leave the module as the unit of encapsulation, but it would add a second type of privacy. I don't know if that would convince Walter, but AFAICT, this change wouldn't lead to requests to add friend to the language.

On Thursday, 25 April 2024 at 19:48:11 UTC, Jonathan M Davis wrote:
> On Wednesday, April 24, 2024 11:53:18 PM MDT Richard (Rikki) Andrew Cattermole via dip.ideas wrote:
>> Apart from literature review type content, there isn't much to discuss here. There is nothing to tune.
>>
>> I suggest you start work on a draft DIP and move to development unless Walter or Atila have strong opinions against it.
>
> Well, Walter has consistently shot down requests for this kind of feature in the past (and there was a discussion in the newsgroup within just the past couple of months where it came up IIRC, and Walter shot it down then), so unless someone can come up with a really compelling reason why it's needed, it's going to be shot down. Unless something has changed quite recently, Walter's opinion on this has already been made quite clear, and it's been the same for years.
>
> The normal answer is that if you really need the other code in the module to not have access to the class' members, then that class should just go in another module. In practice, the current situation rarely causes problems. It seems more to be something that annoys some folks on principle rather than being an actual technical issue. I would be shocked if this DIP went anywhere.
>
> - Jonathan M Davis

The requirement in D, that there be no other code in a module (including unittests), other than a class, in order to demonstrate to the compiler (and those that read the code) that the class is meant to be truly encapsulated, is a consequence of the module being the unit of encapsulation.

Allowing a class to explicately define its encapsulated properties, seems to me, a much better solution, and consistent with what most people who use class-oriented oop would expect.

It would also solve consequences (1) and (2) outline in my opening remark.

(1) It makes it difficult to reason about a class definition in a module, when there is other code in the module, as all other code in the module is in essence a part of the class definition.

(2) It allows for accidental, unintended use of a private member by other code in the module, including unittests.

In the example below, neither the compiler nor someone reading the code, would know that the class is being used incorrectly in this unittest. Only by allowing the programmer of the class to be explicit about the encapsulated properties of the class, can the compiler and those reading this code below, identify the problem.

Yes, you could say the programmer must put the unittest in a separate module to the class, and then the unitttest can be interpreted correctly. But this extra burden on the programmer in completely unnessecary if D has something like private(this).

As for Walters opinion on this, I don't think I can recall ever seeing it, let alone any explanation for that opinion. But here and now seems like the best place to voice that, don't you think?

I've already given reasons for why this feature would be useful. The reasons are valid.

Objections to this idea should have there reasons as well, so we can test the validity of those objections.

btw. The problem in the code below, is one of 'principle'.


// --
module m;

class C
{
  private int _count; // visibilty of this member extends to the entire module.
  public void setCount(int c) { _count = c; }
}

unittest
{
  C c = new C();
  c._count = 42; // Actually, this is a mistake, and the programmer should be testing the public method setCount(..)
}

// ----

On Thursday, 25 April 2024 at 22:47:17 UTC, NotYouAgain wrote:
>
> ..

oops.

that should have been: "btw. The problem in the code below, is NOT one of 'principle'."

On Thursday, 25 April 2024 at 13:35:29 UTC, Nick Treleaven wrote:
> It should say whether __traits(getMember), allMembers and .tupleof can access private(this) members.
> ..
> ...

This unittest would pass:

module m;
@safe:
import std;

    class C
    {
      private(this):
        int x;
    }

    unittest
    {
        auto c = new C;

        static assert(__traits(getVisibility, C.x) == "private(this)");
        static assert(__traits(hasMember, C, "x") == true);
    }

On Thursday, 25 April 2024 at 16:40:30 UTC, Quirin Schroll wrote:
> On Thursday, 25 April 2024 at 05:37:24 UTC, NotYouAgain wrote:
>> […]
>
> I don’t know why, but I find `private(this)` looks weird. It makes me think I can put other things in the parentheses – which is not the case. How about `super private`? `super` is already a keyword. Yes, it’s a little bit tongue-in-cheek, but I honestly like it more than `private(this)`.

Do I take it, that you're in agreement, that this is a solution to a problem, and that you're just uncomfortable with how private(this) looks?

If so... you can already do things like this in D:

    struct A
    {
        this(this) {}
    }

On Thursday, 25 April 2024 at 13:35:29 UTC, Nick Treleaven wrote:
> It should say whether __traits(getMember), allMembers and .tupleof can access private(this) members.
> ..
> ....

Yes, this would pass as well:
(btw. you can test all this in OpenD, as it already has private(this)

module m;
@safe:
import std;

class C
{
  private(this):
    int x;
}

unittest
{
    auto c = new C;

    foreach (i, ref part; c.tupleof)
        writeln(__traits(identifier, c.tupleof[i]));
}

On Thursday, 25 April 2024 at 17:14:23 UTC, monkyyy wrote:
> ..
> ...
> shouldnt it be `private alias this this;`

There are 2 ways I can interpret your contribution to this discussion.

(1) You believe 'private alias this this;' is better that 'private(this)'

(2) You are being derisive

If it is the former, I don't agree.

If it is the latter, I don't believe that derision is in the spirit of the guidelines for this forum group.