On Friday, 26 April 2024 at 00:36:37 UTC, NotYouAgain wrote:
>
> If it is the latter, I don't believe that derision is in the spirit of the guidelines for this forum group.

I aint one for rules, but if your hall monitoring I would think accusing others of bad faith is worth twisting the knife. If I was being "derisive" I would be commenting on how oo should be removed from the language entirely; at minimum.

oo-philes may not understand `alias this` statements, fine, but to break down `private alias this this`, `alias this` must use old fashioned alias statements so essentially its saying `private alias this=this`; given alias this is where the special case handling of a struct lives, and my understanding is `private` prepending statements is how to break otherwise perfectly good code for "safety" so I completely stand by my suggestion.

On Friday, 26 April 2024 at 02:27:49 UTC, monkyyy wrote:
> On Friday, 26 April 2024 at 00:36:37 UTC, NotYouAgain wrote:
>>
>> If it is the latter, I don't believe that derision is in the spirit of the guidelines for this forum group.
>
> I aint one for rules, but if your hall monitoring I would think accusing others of bad faith is worth twisting the knife. If I was being "derisive" I would be commenting on how oo should be removed from the language entirely; at minimum.
>
> oo-philes may not understand `alias this` statements, fine, but to break down `private alias this this`, `alias this` must use old fashioned alias statements so essentially its saying `private alias this=this`; given alias this is where the special case handling of a struct lives, and my understanding is `private` prepending statements is how to break otherwise perfectly good code for "safety" so I completely stand by my suggestion.

sorry. I still don't understand what your input to this discussion is (appart from that you don't like oop).

Are you're saying you weren't being derisive, but you genuinely prefer 'private alias this this;' to 'private(this)'?

On Thursday, 25 April 2024 at 09:31:06 UTC, Kagamin wrote:
>...
> Nested classes.

I believe that private(this) needs to always be consistent with its meaning.
Altering its meaning for nested classes would not be appropriate.
There is no code breakage. One simply can choose not to use private(this).

class Outer
{
    private(this) int m;

    class Inner
    {
        private int foo()
        {
            return m;   // Error: class `test.Outer` variable `m` is not accessible

        }
    }

}

On Thursday, 25 April 2024 at 12:55:33 UTC, 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`.

Yes, private(this) is more restricted, only in that it applies concept of private to the type - which is what the vast majority of class-oriented oo programmers would expect.

And being able to 'explicetly' ensapsulate a member to the type itself, is a no-brainer to oop programmers. But they can't do that in D.

In an ideal world, D would have done what Swift did - and have 'private' mean what most oop's would expect it to mean (that is, restricted to the enclosing declaration), and 'file-private' to mean what private means in D (that is, private to the module file).

But its rarely and ideal world.

A breaking change to fix this would *never* be accepted, *understandably*.

this(this) is an already available construct in D.

private(this) seems the best way to proceed I believe, since it *does* need to have the word 'private' in it, which is what any oop would expect.

 - 'strongprivate' suggest nothing really.
 - 'hidden' lacks clarity of its meaning.
 - 'private(this)' - private to 'this' (ie. this type) .. seems to me, to bring sufficient clarity to the construct, especially since the notion of 'this' is already clear in D classes.

Therefore private(this) seems the most sensible way to implement this - at this stage, given the above points.

On Thursday, 25 April 2024 at 05:37:24 UTC, NotYouAgain wrote:
>

In anticipation of this new question (what happens it you use private(this) in global scope?

I can answer this below (in code):

module m;
@safe:

import std;

private(this) int x; // Error: visibility attribute `private(this)` cannot be used in global scope

void main(){}

On Friday, 26 April 2024 at 05:48:03 UTC, NotYouAgain wrote:
> On Thursday, 25 April 2024 at 09:31:06 UTC, Kagamin wrote:
>>...
>> Nested classes.
>

And...

class Outer
{
    Inner newInner()
    {
        return new Inner();
    }

    class Inner
    {
        private(this) this() //  Error: class `EZ_Compiler_tmpfile.Outer.Inner` constructor `this` is not accessible
        {

        }
    }
}

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.
>
> private(this) maybe should be the default for synchronized classes.
>

Does that mean, that 'private(this)' would solve:

https://issues.dlang.org/show_bug.cgi?id=23158

On Thursday, 25 April 2024 at 19:48:11 UTC, Jonathan M Davis wrote:
> ..
> ...
> 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

Another example, again, not on principle, but an actual issue.

The class below is from: https://dlang.org/spec/class.html#invariants

Sadly, the invariant here is ignored when I access the private member directly.

The below will pass the unittest.

However, by changing:
private:
    int day;
    int hour;

to:
private(this):
    int day;
    int hour;
not only has the author made their intent clear (as they have the tool to do it with private(this), but the compiler will now know the intent as well, and will rightly refuse to compile the code.

// ---------------
module m;
@safe:
import std;

class Date
{
    this(int d, int h)
    {
        day = d;    // days are 1..31
        hour = h;   // hours are 0..23
    }

    invariant
    {
        assert(1 <= day && day <= 31);
        assert(0 <= hour && hour < 24);
    }

  private:
    int day;
    int hour;
}

unittest
{
    Date d = new Date(1,1);
    d.day = 0; // invariant has no effect here.
               // day/hour really should not be accessible here anyway
               // - but there's no way in D to prevent this,
               // except by putting the unittest in a separate module to the class.
}
// -----------

On Thursday, 25 April 2024 at 05:37:24 UTC, NotYouAgain wrote:
>

fyi.. for those interested in the source code changes that were needed to implement private(this):

https://github.com/dlang/dmd/compare/master...dkorpel:dmd:private-this#diff-8da4a723a20020bf5d1edf1a9f1344eb776c73a0ae35ccee95d3bc24cb0600a7R242

On Friday, 26 April 2024 at 10:44:11 UTC, NotYouAgain wrote:
> On Thursday, 25 April 2024 at 05:37:24 UTC, NotYouAgain wrote:
>>
>
> fyi.. for those interested in the source code changes that were needed to implement private(this):
>
> https://github.com/dlang/dmd/compare/master...dkorpel:dmd:private-this#diff-8da4a723a20020bf5d1edf1a9f1344eb776c73a0ae35ccee95d3bc24cb0600a7R242

oops:

https://github.com/opendlang/opend/commit/3f77889a26043e1a0a82e27ace80b2d2285b4ad8