Hello to all,

I'm starting to program in Dlang. I use for the moment the online editor.

I test the following code:

import std;

class User
{

    private string name;

private:
    string firstname;
    int age;

public:

    override string toString()
    {
        return (format("User: %s %s - (%s)", this.name, this.firstname, this.age));
    }

};

void main()
{

    auto bob = new User();
    bob.name = "Bob";
    bob.firstname = "McDean";
    bob.age = 15;

    writeln(bob);

}

and I don't understand why I can modify private members from outside my class.

I had understood that it was required to create accessors to have this behavior.

Thanks in advance to all for your welcome and your answers.

Christophe__c

On Monday, 21 June 2021 at 10:01:03 UTC, christophe__c wrote:

import std;

class User
{

    private string name;

private:
    string firstname;
    int age;

public:

    override string toString()
    {
        return (format("User: %s %s - (%s)", this.name, this.firstname, this.age));
    }

};

void main()
{

    auto bob = new User();
    bob.name = "Bob";
    bob.firstname = "McDean";
    bob.age = 15;

    writeln(bob);

}

Ah this gain ;)

in D "private" is related to the module scope, not the aggregate scope.
So at the module scope you can see private declarations even if the "local" scope
is unrelated.

On 6/21/21 6:01 AM, christophe__c wrote:

Welcome to the community!

Just FYI, these kinds of questions should go into the learn forum

And user1234's answer is correct, D's private applies to module scope, not struct/class scope. The main reason is so D can avoid the friend requirements of C++.

It's also pretty reasonable, since anyone who can edit the class can also edit the rest of the file. However, it can make things difficult when proving correctness if you don't have a "one class per module" setup.

-Steve

On Monday, 21 June 2021 at 13:09:31 UTC, Steven Schveighoffer wrote:

Good evening Steve, Good evening user1234

Thank you very much for your answers. I have to admit that I am disappointed by this behavior.

I'm sorry I posted in the wrong forum.

Good evening to you.

-Christophe

On Monday, 21 June 2021 at 20:18:03 UTC, christophe__c wrote:

As suggested ("this again") this is a recurrent question. I have myself nothing against strict privacy but the problem is that it would require a new keyword as obviously nobody wants to change the semantics of "private".

On Tuesday, 22 June 2021 at 02:37:28 UTC, user1234 wrote:

I think actually that "super private" would work.

struct S {
   super private:
     static int a;
   private:
      static void test() {
        a = 0;
      }
}

void test() {
  S.test(); // Ok
  S.a = 0;  // NG
}

Who cares could write a DIP.

On Wednesday, 23 June 2021 at 07:04:05 UTC, user1234 wrote:

We already have the means to handle this for people who really really want it. Make the module a package and put all of the SuperSecretSauce ingredients in their own modules.

• mymodulepackage
  -- package.d
  -- opensecrets.d
  -- supersecretsauce1.d
  -- supersecretsauce2.d

Package protection lets you share whatever needs to be shared between each module, you are able to fully restrict access to private members, and clients are able to import mymodulepackage without worrying about the details.

On Wednesday, 23 June 2021 at 07:29:54 UTC, Mike Parker wrote:

ah lol, speaking of hidden secrets, I did not know that you handled sarcasms with such a talent.

I know i know... we are talking on things that are extremely simple to implement but that wont wont be done by design principle.

On Wednesday, 23 June 2021 at 07:04:05 UTC, user1234 wrote:

What problem does this solve?

On Monday, 21 June 2021 at 20:18:03 UTC, christophe__c wrote:

Why are you disappointed?