On Thursday, 16 June 2022 at 11:40:16 UTC, forkit wrote:
> On Thursday, 16 June 2022 at 11:31:48 UTC, Ola Fosheim Grøstad wrote:
>> On Thursday, 16 June 2022 at 11:26:23 UTC, forkit wrote:
>>> [...]
>>
>> I think I have, but I can do it again:
>>
>> Since D has meta programming capabilities it can affect meta programming code that makes assumptions about access control modes being fixed to the existing set.
>>
>> As such it will be a breaking change, but will probably not break most programs.
>>
>> (Basically all changes that go beyond syntax sugar are breaking changes in D.)
>
> ok, except you too ;-)
>
> I must have missed this in all the nonsense going on...
>
> the constraint is optional, just as using meta programming is optional.
>
> but if the D language requires that 'meta programming in D must be able to access class members that are private to the scope of the class', then assuming this would not be the case if the suggestion were implemented, then we have a first, genuine, issue to consider  ;-)

you are always fast to dismiss any potential problems. Write a DIP. Add all possible ways in which adding _class private_ will affect/break existing code.
for starters: __traits(getVisibility), .tupleof, std.traits.hasMember, std.traits.hasStaticMember

On Tuesday, 21 June 2022 at 11:05:10 UTC, The Zealot wrote:
>
> you are always fast to dismiss any potential problems. Write a DIP. Add all possible ways in which adding _class private_ will affect/break existing code.
> for starters: __traits(getVisibility), .tupleof, std.traits.hasMember, std.traits.hasStaticMember

They're already broken today without class private.

Or at least .tupleof and hasMember is.

Depending on how it's added then it won't add any breakage to those as existing code will still yield the same results, it will only be for new code where there'll be a difference and arguably neither of those should return any class private members.

It should work just as it do today in theory.

The only difference will be in future apis exposed.

Example where nothing changes:

Today:

```
class Foo
{
  int x;
  int y;
}

// exposed: x,y
```

If class private existed:

```

class Foo
{
  int x;
  int y;
  hidden int z;
}

// exposed: x,y
```

Example where something changes:

Today:
```
class Foo
{
  int x;
  int y;
  int z;
}

// exposed: x,y,z
```

If class private existed:

```
class Foo
{
  int x;
  int y;
  hidden int z;
}

// exposed: x,y
// breaking change in this case only
// clearly you would mark this as a breaking change in the new release
// that is not a problem for libraries and/or user code - it's only a problem for ex. phobos
// arguably phobos would just never change anything to class private
```

On Tuesday, 21 June 2022 at 11:05:10 UTC, The Zealot wrote:
>
> you are always fast to dismiss any potential problems. Write a DIP. Add all possible ways in which adding _class private_ will affect/break existing code.
> for starters: __traits(getVisibility), .tupleof, std.traits.hasMember, std.traits.hasStaticMember

Well, I'd argue the opposite - i.e. that too many in the D community are always fast to dismiss any potential problems.

'this is how we do it in D, so there!'

'our language doesn't need to give you that option. instead, we'd rather force you into putting every class into its own module.'.

The vast majority of programmers have a different concept of the class, to what D is wanting to **impose** on them.

Can you even see the problem here?

The problem is certainly NOT a result of wanting 'an option' to make a member private within the specification of a class.

You may retort.. I know you will ;-)

// ----

module test;
@safe:

class Base { private int x = 100; }
class Derived : Base {}

void main()
{
    import std.stdio : writeln;

    Derived d = new Derived();
    writeln(d.x); // this is so sad.
}

// ----

On Tuesday, 21 June 2022 at 11:05:10 UTC, The Zealot wrote:
>

and btw:


"Java's notion of one class per module is a bit too restrictive, as one may desire a set of closely interrelated classes that encapsulate a concept, and those should go into a module." - Walter Bright

https://forum.dlang.org/post/pr110b$9j5$1@digitalmars.com

Oh great. He does get it afterall.

But what if you want closely interrelated classes that encapsulate a concept, in the same module, but don't want every class to have complete access to every part of every other class......

Oh. I know, just put each class in it's own module.

On Tuesday, 21 June 2022 at 23:36:06 UTC, forkit wrote:
> On Tuesday, 21 June 2022 at 11:05:10 UTC, The Zealot wrote:
>>
>> you are always fast to dismiss any potential problems. Write a DIP. Add all possible ways in which adding _class private_ will affect/break existing code.
>> for starters: __traits(getVisibility), .tupleof, std.traits.hasMember, std.traits.hasStaticMember
>
> Well, I'd argue the opposite - i.e. that too many in the D community are always fast to dismiss any potential problems.
>
> 'this is how we do it in D, so there!'
>
> 'our language doesn't need to give you that option. instead, we'd rather force you into putting every class into its own module.'.
>
> The vast majority of programmers have a different concept of the class, to what D is wanting to **impose** on them.
>
> Can you even see the problem here?
>
> The problem is certainly NOT a result of wanting 'an option' to make a member private within the specification of a class.
>
> You may retort.. I know you will ;-)
>
> // ----
>
> module test;
> @safe:
>
> class Base { private int x = 100; }
> class Derived : Base {}
>
> void main()
> {
>     import std.stdio : writeln;
>
>     Derived d = new Derived();
>     writeln(d.x); // this is so sad.
> }
>
> // ----

```
module test;
import std.stdio;

@safe:
interface IDerived {
    void fine() @safe;
}

IDerived createDerived() {
    static class Base { private int x = 100;  }
    static class Derived : Base, IDerived { void fine()@safe{writeln(x);} }
    return new Derived();
}

void main()
{
    import std.stdio : writeln;

    auto d = createDerived();
    d.fine();
    writeln(d.x); // look, no access.
}
```

On Thursday, 23 June 2022 at 10:55:17 UTC, The Zealot wrote:
>
> ```
> module test;
> import std.stdio;
>
> @safe:
> interface IDerived {
>     void fine() @safe;
> }
>
> IDerived createDerived() {
>     static class Base { private int x = 100;  }
>     static class Derived : Base, IDerived { void fine()@safe{writeln(x);} }
>     return new Derived();
> }
>
> void main()
> {
>     import std.stdio : writeln;
>
>     auto d = createDerived();
>     d.fine();
>     writeln(d.x); // look, no access.
> }
> ```

That is certainly interesting ;-)

However, it looks like a lot of work, just to limit access to a class member :-(

I was rethinking how I could 're-frame' my argument, in light of that 'Civility' thread.

Perhaps like this:

i.e. what is the value of having keyword 'const' in this code below?

I mean, if you want the string to remain constant, then don't change it.

Why bother using 'const'? Let's just get rid of const. It's kinda pointless, since you're the programmer, writing the code.

The answer is simple. The compiler can statically **guarantee** the correctness of your program. You do not even have to worry about making a mistake, and accidently modifying it.

Imagine if 'my programming language', said to you, we don't have the keyword 'const'. If you want it const, then don't change it. Or, put the function in its own module, so that it can't be changed.

So I do not see the difference, between the benefit of having const, and the benefit of having private(this). Both provide static verification of your program. There is no downside to that, IMO.

Obtaining static verification makes for a worthwhile addition to the language, IMO. It's not just some fad I want to bring into D, cause other languages have it.

I'm not sure this re-framing of my argument will help, but, this is my last hoorahhh on this topic ;-)

// ---
module test;
@safe:

import std;

void main()
{
    printString("Hello World!");
}

void printString(const string str)
{
    writeln(str);
}

// ----

On 15.06.22 12:57, Abdulhaq wrote:
> On Tuesday, 14 June 2022 at 20:22:17 UTC, Dom Disc wrote:
>> class C
>> {
>>    private int _hidden_x;
>>    private int _hidden_y;
>>    @limitPrivateAccess(_hidden_x) foo(x)
>>    {
>>       _hidden_x = x;
>>       _hidden_y = 0; // error: foo has no access to _hidden_y
>>    }
>> }
>>
>> So foo would normally have access to _hidden_y although the developer doesn't want that. That is so because today _all_ member functions (and friends) have access to _all_ private variables. The new UDA @limitPrivateAccess restrict this to only those private variables given as its parameters.
>> Together with a new privacy-level "@hidden" we could even have variables that no-one has access to, except those functions that are explicitly allowed to access them via the UDA. This would be the ultimate restriction level.
> 
> my mind is boggling LOL
> 
> seriously though, the access restrictions must be declared by the provider, to limit the notional consumer. Here the provider is restricting itself, it's pointless.

It's not pointless. It's automatically checked code documentation. There are surprisingly many vocal programmers who argue as if they never wrote software in a team (possibly with turnover).

On Sunday, 26 June 2022 at 00:44:48 UTC, Timon Gehr wrote:
> There are surprisingly many vocal programmers who argue as if they never wrote software in a team (possibly with turnover).

It is difficult to work in a group when you're omnipotent.

On Tuesday, 14 June 2022 at 20:22:17 UTC, Dom Disc wrote:
> On Tuesday, 14 June 2022 at 19:39:40 UTC, Paul Backus wrote:
>> If a function doesn't need access to private member variables, don't implement it as a member function. Instead, put it in a separate module and call it using UFCS.
> Yes, that is nice.
> But the most common usecase is that the class has multiple private variables, and each member function needs only access to some of them.
> Today there is no way to express to which of them a function should have access and to which not.
> My idea was the following:
>
> class C
> {
>    private int _hidden_x;
>    private int _hidden_y;
>    @limitPrivateAccess(_hidden_x) foo(x)
>    {
>       _hidden_x = x;
>       _hidden_y = 0; // error: foo has no access to _hidden_y
>    }
> }
>
> So foo would normally have access to _hidden_y although the developer doesn't want that. That is so because today _all_ member functions (and friends) have access to _all_ private variables. The new UDA @limitPrivateAccess restrict this to only those private variables given as its parameters.
> Together with a new privacy-level "@hidden" we could even have variables that no-one has access to, except those functions that are explicitly allowed to access them via the UDA. This would be the ultimate restriction level.

I kinda like this... just as an 'idea', at this stage.

I'm certainly not suggesting we should do it. But discussions are always worthwhile.

But some classes can indeed be very long....even necessarily so.

I'd like the concept to make use of the existing invariants() method.

i.e some attribute that can only be used, and only makes sense, when used in that method.

the ultimate (and only) aim here, is to enhance the provability of the program, through static compile time checking (which can't be done unless you can first express intent).

e.g:

(and no. I haven't thought this through very much at all).

class C
{
    private(this):
     int x, y, z;

    invariant()
    {
        // restrict certain member functions to certain member variables.
        assert( @restrictedMemberAccess {x, y : setXY, getX, getY};
    }

    setXY(int x, int y) { x = x; y = y } // fine
    int getX( return x); // fine
    int getY( return y); // fine

    void foo( x = 0; ); // noCanDo! foo is not in the above list.
    void bar( z = 0; ); // fine. no invariants declared. so normal rules apply.
}

Destroy!

On Sunday, 26 June 2022 at 01:28:46 UTC, forkit wrote:
>

Here I introduce a new concept, which (for now), we'll call a 'view'.

It can solve multiple problems.

First, it eliminated a need for 'private(this)'

Second, it allows fine grained control of member access, to member variables.

Anything declared private, in a view, is simply private to that view.


class myClass
{
    @view
    {
        private:
          int x;

    	public:
          void setX(int x) { this.x = x; }
          int getX( return this.x; }
    }


    private:
      void fred() { this.x = -1; }  // error: fred is not part of the view that contains x
      int waldo() { return this.x; } // error: waldo is not part of the view that contains x

    public:
      void foo() { this.x = -1; }  // error: foo is not part of the view that contains x
      int bar() { return this.x; } // error: bar is not part of the view that contains x
}