Code That Says Exactly What It Means

[Peter C]

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.