On Friday, 26 January 2024 at 22:21:22 UTC, Meta wrote:
>
> This is the only valid reason for introducing class-private that's ever been put forth in this forum. I saw someone else post a similar argument around class invariants awhile back as well and it completely changed my mind on the issue.

This has been argued before, but in a slightly different manner.

Objects have type (i.e. the object is of type class).

As a type, it must be able to present its interface to other code in a way that maintains its invariants.

In this view, a class is no different to other types in the language, which also maintain their invariants.

The key here, is to think of a class as a type. If you don't think that way about classes, then class(private) would seem a pretty useless addition to the langauge.

But without a class(private) option, there is simply no way for a class 'type' to maintain its invariants in D, when other code is in the same module as the class. This includes code for unittests.

The only workaround in D, is to ensure a module (file) contains no other code other than that single class.

While module level visibility is very useful, the usefulness of class level visibility is not really something that anyone should have to justify. A class is a type, and therefore should have the ability to maintains its invariants, even from other code in the same module.

That, I would argue, is the primary reason for introducing an option in D for class(private).

It's not an argument for OOP. It's an arguement to allow a class type in D, to be able to present itself 'as type that can maintain its own invariants' to other code in the same module. The key part there is 'to other code in the same module'. This cannot occur without a class level visibility attribute.

The only argument that be put forward against this arguement, is that in D, you shouldn't ever need to present a class as 'a type that can maintain its own invariants' to other in the same module.

But when a programmer has that need, D cannot provide a solution.

class(private) would immediately solve that problem, for that programmer.

On Thursday, 25 January 2024 at 00:19:54 UTC, Jordan Wilson wrote:
>
> ...
> That wasn't what was said. What was said was "causing US problems". I.e. on the whole, the lack of class-level privacy does not appear to be causing widespread problems, which implies that it's simply lower on the list of feature requests for most people.
>

Allowing mutable state to escape - the confines of the type in which it has been declared - into the whole of the module, will inevitably lead to a problem.

My first use of the D language demonstrated that this statement is factual.

The more 'widespread' D is used, will 'likely' also demonstrate the same.

Having a means to control what state can or can't escape into the rest of the module seems like a pretty sensible option to have - at least to me.

Again, the only argument that has been put forward against this, is that in D you can put your type into its own module. That is, one module for every class, and for every unittest.

That can end up to be a lot of files needing to be managed, simply to control the escape of state into a module.

On Friday, 26 January 2024 at 23:41:51 UTC, FairEnough wrote:
> That can end up to be a lot of files needing to be managed, simply to control the escape of state into a module.

In case you’re worried about the clarity in your editor’s file list (or in similar tools), try packagizing your modules; that should lead to folders that are easily collapsible.

In case you’re worried about running out of inodes on ext4 filesystems, maybe give XFS a try.

On Monday, 22 January 2024 at 22:59:17 UTC, Walter Bright wrote:
>
> ...
> C++ private isn't private, const isn't constant, and one can throw from nothrow functions.
>

But that, vI assume you mean that in C++ you can return pointers/references to private mutable class members, and therefore 'private isn't private'.

If that is what you're referring to, then that does not negate the value of class private members in C++.

Nor is it argument against an option for class private members *within* a module, in D.

There is only 1 valid argument against introducing an option for module level class private members in D. And that is, a programmer (as in all programmers who use D) should never need to control the visibility of a class types mutable state to other code in the same module (including unittests).

But is that true?

I mean either it is, or it isn't.

The option presented, i.e. to put the class type in a module by itself, does not answer this question (since there is no other code in the module).

Any answer to this question has to take into account the other code in the module.

On Saturday, 27 January 2024 at 02:12:25 UTC, FairEnough wrote:
>
> ..
> Any answer to this question has to take into account the other code in the module.

Of course, I can answer this question.

The code below demonstrates how D made it possible for me to make a mistake when I first used D (i.e. I had the unittest in the same module as the class).

Of course now I know, silly me, just put the unittest in its own file god-damitt!

But here is how that mistake could have been avoided without having to put that unittest in its very own module:

module someClass;

class C
{
    void increment() {++x;}
    private(this) int x;
}

unittest
{
    auto c = new C;
    c.x++; // it seems to me, that this is not what that 'type' expects.
    c.increment(); // Thanks private(this) for helping me not make that mistake.
}

On Saturday, 27 January 2024 at 01:57:01 UTC, Elias (0xEAB) wrote:
> On Friday, 26 January 2024 at 23:41:51 UTC, FairEnough wrote:
>> That can end up to be a lot of files needing to be managed, simply to control the escape of state into a module.
>
> In case you’re worried about the clarity in your editor’s file list (or in similar tools), try packagizing your modules; that should lead to folders that are easily collapsible.
>
> In case you’re worried about running out of inodes on ext4 filesystems, maybe give XFS a try.

No, not really worried about running out of inodes ;-)

My interests are in types that are correct (in both design and use) and enforcable (at least to a reasonable extent).

Without private(this) you cannot determine the intent of that types use by other code in the module. And you certainly cannot enforce it. This is true for all other code, including code for unitttests.

Without private(this), you *always* leak *all* of the types state into the rest of the module. Hence the workaround of putting every type in its own module, and every unittest making use of that type in a separate module to that type.

Otherwise, leaky state will inevitably bite you (unless you're one of those programmers that never make mistakes).