On 1/21/2024 3:46 AM, Dom DiSc wrote:
> `class-private` is superfluous cruft. You can very easy live without it.
> And it has only no side effects, if it is implemented without `friend`s. But without this misfeature it is incomplete.
> Therefor it was decided not to implement it.
> 
> It would be ok for me to add `class-private` as is, but only with the guarantee that `friend`s will never be added, no matter how much the  people using it cry, because it is sometimes unusable without them.

The irony is that the presence of class private in C++ wound up motivating the friends feature, which violates private left and right. D did it right with module level privacy, which is enforced.

C++ private isn't private, const isn't constant, and one can throw from nothrow functions.

D users do ask for non-constant const, impure pure, and GC allocating @nogc. You *can* do these things in D by using forcible casts in @system code. The salient difference between that and C++ is that the D compiler still assumes those invariants are in force, whereas C++ compilers cannot.

On 1/21/2024 3:51 AM, zjh wrote:
> When you need `friend`, You can put them all in one module.
> Sometimes, when `multiple classes` are closely related and independent, `class level privacy` becomes very important. No one wants , someone from outside may secretly steal money from your home.


D does not allow a different module accessing private class members. Private access is limited to the module enclosing that class.

This encourages a different use of modules than C++ "toss code randomly into different source files."

On Monday, January 22, 2024 4:01:54 PM MST Walter Bright via Digitalmars-d- announce wrote:
> On 1/21/2024 3:51 AM, zjh wrote:
> > When you need `friend`, You can put them all in one module.
> > Sometimes, when `multiple classes` are closely related and independent,
> > `class level privacy` becomes very important. No one wants , someone from
> > outside may secretly steal money from your home.
>
> D does not allow a different module accessing private class members. Private access is limited to the module enclosing that class.
>
> This encourages a different use of modules than C++ "toss code randomly into different source files."

It also greatly simplifies having to deal with visibility attributes. I can understand folks being concerned about it at first, but in practice, it really isn't a problem.

If it really is a problem for a piece of code to have access to something private that's in the same module, then you can simply put them in separate modules, and if your module is large enough that you can't keep track of that sort of thing like you need to, then it should probably be split up.

And for those cases where you need cross-module access without it being public, there's always the package attribute.

The end result is that visibility attributes are very easy to reason about, and you don't have to worry about them much. I really think that the folks who insist on having private be private to the class/struct (or who insist on a new attribute which does that) are just too tied to how other languages work and haven't given D's approach a chance. I don't think that I have _ever_ seen a problem stem from the fact that D's private is private to the module. And in fact, it causes so few issues that way that plenty of folks end up being surprised to find out that it works that way, because they've never run into a situation where it actually mattered that it wasn't private to the class/struct.

Of course, ultimately, different programmers have different preferences, and none of us are going to be happy about everything in any language. So, of course, there are going to be some folks who are unhappy with how D defines private, but it's not a feature that has actually been causing us problems, and it really doesn't make sense at this point to change how it works.

- Jonathan M Davis

On Monday, 22 January 2024 at 23:01:54 UTC, Walter Bright wrote:
> On 1/21/2024 3:51 AM, zjh wrote:
>> When you need `friend`, You can put them all in one module.
>> Sometimes, when `multiple classes` are closely related and independent, `class level privacy` becomes very important. No one wants , someone from outside may secretly steal money from your home.
>
>
> D does not allow a different module accessing private class members. Private access is limited to the module enclosing that class.
>
> This encourages a different use of modules than C++ "toss code randomly into different source files."

These are redherring arguments against a robust principle of OOP.

A private attribute within a class (visible only to that class) does not mean people can now go and 'toss code randomly into source files. Nor should it be compared to people wanting 'non-constant const, impure pure, and GC allocating @nogc.'

Nor would it require D adopting the C++ notion of friends. (all source in a D module is already the D like friend feature anyway, it just implicit).

Nor should it be classified as a 'bad' feature because of maintenance costs.

Nor is it an argument that D move away from module level privacy.

These are all redherring arguments.

There doesn't seem to be any real technical reason as to why D should not allow that option. Swift has done this successfully (for example).

There are only ever redherring arguments put forward, along with the usual 'we don't do it that way in D' argument.

I'm not here to argue for the feature anyway. But given the importance of class-private in OOP, I'd just like to see much better thoughtout arguments against it. (i.e technical/engineering arguments, not the fluff that always accompanies this topic.

Putting everything into there own source files, and this includes unittests of course (since they too can end up inadvertingly testing the wrong part of a class), is a solution  - but a solution for some, but not others.

Anyway, this topic really belongs elsewhere now. But if/when it does popup again, can we please hear better arguments against it, rather than the fluff above, which is not at all convincing.

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.

TIL C++ is worse than anticipated.

On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis wrote:
>
> ...
> but it's not a feature that has actually been causing us problems, and it really doesn't make sense at this point to change how it works.
>
> - Jonathan M Davis

I don't agree.

The first time I used the D language, I discovered a 'problem'.

That is, my unittest inadvertently accessed a private member of a class, instead of using the public interface of the class.

Now the problem of course was me, the programmer (at least one could argue that).

But to me, the problem was the language, for not having a feature that could have avoided this problem in the first place.

Now, if I want to use D to program, I have to ensure I don't make the same mistake again, by putting my unittest into there own source files (since the compiler cannot warn me, since the language has no feature to make my intent explicit to it).

That problem has not gone away, and nor can it, without splitting up everything it own source file.

Whether it makes sense to change it now, is a separate argument (and not really one I want to get into, since the arguments against it are always just fluff, and not worthy of my attention).

But the argument that it cannot cause a problem, is already shown to be wrong.

On Wednesday, 24 January 2024 at 22:32:12 UTC, FairEnough wrote:
> On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis wrote:
>>
>> ...
>> but it's not a feature that has actually been causing us problems, and it really doesn't make sense at this point to change how it works.
> But the argument that it cannot cause a problem, is already shown to be wrong.

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.

Let me put it another way.
I'm not against class private. I'm not against string interpolation.
I don't care about class private. I don't care about string interpolation.
One will soon be in the language, and one will not.

I can only assume lack of string interpolation was causing pain to more users, than a lack of class private, therefore it got implemented first.

Jordan