On Thursday, 30 October 2025 at 03:48:01 UTC, Steven Schveighoffer wrote:
> On Thursday, 30 October 2025 at 03:00:02 UTC, jmh530 wrote:
>> On Wednesday, 29 October 2025 at 21:01:03 UTC, Sergey wrote:
>>> [snip]
>>> have different "weight" than from "first time forum poster 3 days ago" or from forkit/claptrap.
>>>
>>> That's why the comparison of the situation with i-strings when it was a discussion between Paul, Adam, Steven, Timon and Walter has nothing to do with messages that popping up every year from the same one single person.
>>> So the pushback in the current situation is understandable.
>>>
>>
>> Are they the same person? I can't keep track. People should just stick with one ID. If it's just one person making a big deal about this, then it would change the calculus.
>
> I think it's unfair to judge all new questions with this lens, it's showing a bias that is not really focused on the topic at hand.
>
> Yes, there was an individual who posted with multiple account names, and this person continually brought up "scopeprivate" or "private(this)" or whatever new incarnation of this tired idea that D should adopt lest it leave behind the millions of developers just waiting to use the language as soon as this gets fixed. But I'm not totally convinced this latest handle is the same person, I will at least give that benefit of doubt.
>
> But that doesn't mean we have to keep entertaining the idea when it's been discussed to death.
>
> Bottom line: D has module private (similar to Java), and this is not going to change, no matter how many pleas are posted here.
>
> There has always been only ONE deficiency for this, and that is documented unittests being allowed to use private symbols in the module. But this is a unittest problem, and not a private problem.
>
> Note that the OPs argument against (non-documented) unittests being able to access private data is ironically something I view as a necessity -- I often test functions on a type and then examine the private details to make sure the state is as I expect it.
>
> This is the last time I'll post on this thread. And probably it should just be dropped.
>
> -Steve

unittests being able to access private data should be put within the scope of the type with that data. This presents a consistent mental model of encapsulation.

My grip with D, is the mental model of encapsulation (that literally millions of programmers already have), is discarded just so D can say 'the module is the unit of encapsulation'.

There is nothing wrong with D saying instead:

That the module is the unit of encapsulation, however, user-defined types (specifically class and structs), can continue to maintain their own invariants when required, by using scopeprivate, and thus the two principles of (1) 'collaboration does not disolve ownership' and (2) 'make things open by default, restrict them only when you mean to', continue to remain true.

To me, that is really not a contraversial idea.

What is controversial to me, is that a module disolves the encapsulation of types.

Perhaps what D should advertise instead, is:

"The module is the unit of encapsulation in D, and thus it disolves the encapsulation of types".

Good luck getting an audience with that ;-)

On Thursday, 30 October 2025 at 03:48:01 UTC, Steven Schveighoffer wrote:
>

An putting aside any idea of adding scopeprivate to D, let's remind ourselves that abstraction is one of the central principles of software engineering, what an abstract data type actually is, and why it's important for it to have the capacity to establish and maintain its own invariants:

https://learn.adacore.com/courses/ada-in-practice/chapters/abstract_data_types.html

If I put these two types in the same module, where you can reasonably argue they belong, then the concerns in the article above become an immediate reality in D:

class Collection
{
    int[] data;

    scopeprivate int _version; // it's vital here that Collection maintain control over this. scopeprivate makes that explicit and enforcable. This is a good thing, not a bad thing.

    this(int[] values)
    {
        data = values.dup;
        _version = 0;
    }

    void add(int value)
    {
        data ~= value;
        _version++;
    }

    int getVersion()
    {
        return _version;
    }
}

class CollectionIterator
{
    private Collection coll;
    private size_t index;
    private int expectedVersion;

    this(Collection c)
    {
        coll = c;
        index = 0;
        expectedVersion = c.getVersion();
    }

    bool hasNext()
    {
        checkForModification();
        return index < coll.data.length;
    }

    int next()
    {
        checkForModification();
        return coll.data[index++];
    }

    private void checkForModification()
    {
        if (coll.getVersion() != expectedVersion)
        {
            throw new Exception("Collection modified during iteration!");
        }
    }
}

On Thursday, 30 October 2025 at 05:23:29 UTC, Peter C wrote:
> On Thursday, 30 October 2025 at 03:48:01 UTC, Steven Schveighoffer wrote:
>>
>
> An putting aside any idea of adding scopeprivate to D, let's remind ourselves that abstraction is one of the central principles of software engineering, what an abstract data type actually is, and why it's important for it to have the capacity to establish and maintain its own invariants:
>
> https://learn.adacore.com/courses/ada-in-practice/chapters/abstract_data_types.html
>
> If I put these two types in the same module, where you can reasonably argue they belong, then the concerns in the article above become an immediate reality in D:
>
> class Collection
> {
>     int[] data;
>
>     scopeprivate int _version; // it's vital here that Collection maintain control over this. scopeprivate makes that explicit and enforcable. This is a good thing, not a bad thing.
>
>     this(int[] values)
>     {
>         data = values.dup;
>         _version = 0;
>     }
>
>     void add(int value)
>     {
>         data ~= value;
>         _version++;
>     }
>
>     int getVersion()
>     {
>         return _version;
>     }
> }
>
> class CollectionIterator
> {
>     private Collection coll;
>     private size_t index;
>     private int expectedVersion;
>
>     this(Collection c)
>     {
>         coll = c;
>         index = 0;
>         expectedVersion = c.getVersion();
>     }
>
>     bool hasNext()
>     {
>         checkForModification();
>         return index < coll.data.length;
>     }
>
>     int next()
>     {
>         checkForModification();
>         return coll.data[index++];
>     }
>
>     private void checkForModification()
>     {
>         if (coll.getVersion() != expectedVersion)
>         {
>             throw new Exception("Collection modified during iteration!");
>         }
>     }
> }

And for those that argue.. well .. in Ada.. packages are the unit of encapsulation too.. so what's the big deal with D having choosing to have the module as the unit of encapsulation?

I'd answer: it is very likely, that if Ada were designed today, in a world dominated by class-oriented programming, the designers would likely blend the two models:

 - Keep packages as the unit of modularity.
 - Give types the ability to maintain their own encapsulation boundary (so invariants are truly type‑owned) - ( which is what a 'scopeprivate' like attribute .. would do).

Then D would align with the modern 'a class maintains its own invariants' model.

Perhaps, that would attract more programmers to D - if indeed that's the objective (since most programmers live in a world where this is the model they work with).

But I am genuinely open to listening to a good, rational argument, make no mistake about that.

But the argument that we do it this way, and that's that, doesn't impress me.

I will leave it here, as it's becoming pretty clear this is a dead issue in this forum.

If programmers are happy with their types encapsulation boundary being disolved completely by the module, that is their perogative, I guess. But it's not the kind of code I want to be writing, reviewing, or maintaining.

On Thursday, 30 October 2025 at 06:21:41 UTC, Peter C wrote:
> If programmers are happy with their types encapsulation boundary being disolved completely by the module, that is their perogative, I guess. But it's not the kind of code I want to be writing, reviewing, or maintaining.

we're not holding you hostage. you are free to pick whatever language suits your needs.

but as i said before, scopeprivate is as good as simply naming your internal variables int ___internal____dont_touch______abc;

you can circumvent both.

On 10/30/25 11:20, Zealot wrote:
> and you can simply do this for the exact same result:

That is a slippery slope. Of course you can manage visibility by convention: python does it, and is widely successful, whether because or in spite of it.

Now the question is that if you go this way... why do you then need any visibility attributes at all? Because to me this seems like the worst of both worlds: you have some attributes enforced by the compiler, and some others enforced by convention. Now that's cognitive load.

Also please don't misunderstand me. While I would prefer and use something like `scopeprivate`, I come from java. This means that having one class per file* feels kind of good enough to me, so I'm not going to make a fuss about it.

*: Actually, you can have more than one class per file, just one public one. But it feels really unidiomatic.

On Thursday, 30 October 2025 at 11:30:47 UTC, Arafel wrote:
> On 10/30/25 11:20, Zealot wrote:
>> and you can simply do this for the exact same result:
>
> That is a slippery slope. Of course you can manage visibility by convention: python does it, and is widely successful, whether because or in spite of it.
>
> Now the question is that if you go this way... why do you then need any visibility attributes at all? Because to me this seems like the worst of both worlds: you have some attributes enforced by the compiler, and some others enforced by convention. Now that's cognitive load.
>
> Also please don't misunderstand me. While I would prefer and use something like `scopeprivate`, I come from java. This means that having one class per file* feels kind of good enough to me, so I'm not going to make a fuss about it.
>
> *: Actually, you can have more than one class per file, just one public one. But it feels really unidiomatic.

the difference is that nothing is stopping you from simply editing the class, when you edit the file anyway, so the protection would just prevent accidental use.
there'S also nothing stopping you from not using scopeprivate, that is also just a convention you'd have to use. sure the compiler would enforce it, but the point is: it's a non issue for it not to do so.