On Thursday, 25 January 2024 at 15:03:41 UTC, Max Samukha wrote:

synchronized class C
{
    private int x;
    private int y;

    invariant () { assert (x == y); }

    static void foo(C c)
    {
        // mutate c
    }
}

Same thing. Yet would still break with some sort of "class-only private"

the unittest case is also similar -- what happens if you put the unittest next to the function being tested? It's now in the class, so it can access "true" private data. Same problems, this even can happen in Java. I don't see what the difference is. Same code, same file, just in a different spot? Seems more like you just need to... not do that.

-Steve

On Sunday, 28 January 2024 at 04:23:06 UTC, Steven Schveighoffer wrote:

There certainly are things you should not do.

There are also things you want the compiler to stop you doing.

And when you use a programming language, where mutable state automatically, by default, and at all times, leaks out of the type into the rest of the module, you may really appreciate the compilers help sometimes.

That's where private(this) comes in handy.

Now this example is pretty small, but imagine debugging this when foo() is all the way down on line 3546!

The intent should be right there in the design of the type. Intent should not be subject to analysis of all the code in the module.

No need to debug this program below, since it will not even compile.

module test;
@safe:

import std;

    class C
    {
        private(this) int x; // intent: other code in this module cannnot mutate this.
        private(this) int y; // intent: other code in this module cannnot mutate this.

        invariant () { assert (x == y); }

        void modifyX() {...}
        void modifyY() {...}
    }


    void foo(C c)
    {
        c.x = 10; // compiler will not compile this code.
        c.modifyX();
    }

On Sunday, 28 January 2024 at 04:47:30 UTC, FairEnough wrote:

    class C
    {
        private(this) int x; // intent: other code in this module cannnot mutate this.
        private(this) int y; // intent: other code in this module cannnot mutate this.

        invariant () { assert (x == y); }

        void modifyX() {...}
        void modifyY() {...}
    }


    void foo(C c)
    {
        c.x = 10; // compiler will not compile this code.
        c.modifyX();
    }

Thank you for posting a very informative example, i think not just myself but everyone else on this forum had completely forgot how class private is supposed to work. In spite of the 1000 or so posts you've made about it.

Keep up the good work!

On Sunday, 28 January 2024 at 04:47:30 UTC, FairEnough wrote:

So 60 some odd posts later...

If you want to beat this pile of mush further, please do it in a new thread. Going forward, any posts I see about private-to-the-module which are off topic in any given thread will be happily deleted. You've hijacked enough of them.

Thanks!

On Sunday, 28 January 2024 at 15:31:24 UTC, Mike Parker wrote:

Well I did specifcally say 55+ posts ago that this topic really should be discussed elsewhere.

But people continued to discuss it anyway - but only my responses raised your annoyance?

Do you mean you would actually allow a thread to discuss this topic, if that were the topic of that thread?

Such threads always get hijacked by irritant people completely opposed to this idea, and you end up killing those threads too.

On Sunday, 28 January 2024 at 15:31:24 UTC, Mike Parker wrote:

Off topic certainly, but a 'pile of mush'?

On Sunday, 28 January 2024 at 15:31:24 UTC, Mike Parker wrote:

No more comments about this in this thread. I promise.

For those who don't consider it 'a pile of mush', here is where it 'can' be discussed (freely I hope):

https://github.com/orgs/opendlang/discussions/11

On Sunday, 28 January 2024 at 22:31:59 UTC, FairEnough wrote:

Thank you.

It can be freely discussed here, too. Just please stop hijacking threads to do it.

As for "pile of mush", it's what the dead horse has been beaten into at this point.