On Tuesday, 7 June 2022 at 05:05:53 UTC, Ola Fosheim Grøstad wrote:

wheather it's annoying, people have solved the problem.
It's funny that you didn't solve the problem.
If you don't need it. You don't have to worry about it at all.
It's so easy,
We solve small problems before solving big ones. It is easy to make mistakes if you try big ones first.

On Tuesday, 7 June 2022 at 07:17:29 UTC, zjh wrote:

In addition, adding class encapsulation is to make up for the deficiency .
It's not that you said adding special cases!
Just like there are men and women, you have to say that there are only men, there is not women. woman is special cases!
Then others just can't help you.

On Tuesday, 7 June 2022 at 07:17:29 UTC, zjh wrote:

D should solve its «big» problems and ignore «small problems». The alternative is to start over from scratch.

If you want «private» to be class only, then change the semantics. You could just make «protected» mean access by inheritance and module.

No need for an endless stream of additions. If it matters, adjust what you've got, don't pile on more pointless details.

(In this case it doesn't matter much, so leave it as it is.)

On Tuesday, 7 June 2022 at 07:23:27 UTC, zjh wrote:

There is no deficiency. What we have is already capable of doing what is needed. @private would only add a new way to do the same in a sightly different (and worse) way. Just because that different way is more like C++ (and less like Java or other languages) is not enough benefit to compensate for the increase in mental burden.

And no, ignoring new features if you don't need them is not working, as often you need to read or even work with code written by others. So you need to understand all features they use and cope with different styles if there is more than one way to do a thing. So it is always better to have only one way to do something, even if that doesn't please everybody.

Think of it like coding style guides: you may not like them because you would prefer a different style, but they increase the readability by large, so learn to live with them!

On Tuesday, 7 June 2022 at 07:50:27 UTC, Ola Fosheim Grøstad wrote:

Hard core programmers are responsible for difficult problems, and ordinary people are responsible for simple problems.
This is not an unimportant issue. It will destroy the encapsulation.
As long as it is ' reasonable ' and can meet the ' needs' of different people, it is no big deal to add it. 'd ' needs to meet people's needs first, and then slowly solve big or difficult problems.
Class privacy is an important and simple problem.
If you solve it, you can attract c++ users easily.
Encapsulation of classes is essential for me. if D don't provide it, it just makes me unhappy .
If c++ programmers think so, why do they use d?
Obviously, just adding a piece of code solves the user's needs.
The success of c++ is to constantly meet the needs of different people. Look at the latest rust and other languages. Which is not complicated? Even 'go' has added 'generic'.

On Tuesday, 7 June 2022 at 07:56:30 UTC, Dom Disc wrote:

This is not style at all, because the changes are very small!
It does not destroy readability, but adds a keyword or attribute .
Small changes and great improvements in class encapsulation .and are well worth it.

On Tuesday, 7 June 2022 at 08:45:49 UTC, zjh wrote:

There are many approaches to encapsulation. Beta, the successor to Simula (the first OOP language) did it on a syntactical level which in some ways is more elegant. There are many takes on encapsulation, most follow Simula, but there is nothing particularly wrong with what D has chosen here.

Maybe «package» and «external» should not have been added! Think about generic programming first, how many cases do you need to deal with? 2 is ok, but annoying. 3 is a bit much. 4, 5, 6++ is way too much.

And you are wrong about C++ programmers. I am a C++ programmer. This is not what makes them complain. Go through the forum archives and you'll see what they complain about.

The success of C++ comes down to it being the first OO-language suitable for desktop applications that made it big, then add performance and being compatible with C.

Rust and Go are not complicated.

Rust makes memory management complicated by requiring a tree-structure. The language itself isn't complicated.

Go is not complicated. Go makes error-handling complicated by not having proper exceptions.

The first batch of Rust users complained about it being too complicated and they have put a serious amount of effort into making memory management annotations less cumbersome.

Go was released as a rather minimal language and has only made marginal additions. Their take on generics is minimal.

TLDR; I strongly disagree.

On Tuesday, 7 June 2022 at 08:49:17 UTC, zjh wrote:

The 'really advantage' of D is to achieve 'small changes' and complete 'big features' with the help of 'attributes'!
So, I like 'attributes'!
This Point, but nobody is blowing!

On Tuesday, 7 June 2022 at 09:05:36 UTC, Ola Fosheim Grøstad wrote:

Class encapsulation is a must for ordinary c++ people!
I am not an expert. I only know that class encapsulation is very cool, at least more comfortable than module encapsulation.

On Tuesday, 7 June 2022 at 09:09:52 UTC, zjh wrote:

C++ developers are used to class encapsulation.
Moreover, this kind of "minimal" encapsulation, the "c++" developers, has been deeply rooted in the hearts of the people, and no one complains,like it doesn't exist!
But in 'd', there is no 'class encapsulation' , which is unthinkable!