On Thursday, 25 April 2024 at 05:53:18 UTC, Richard (Rikki) Andrew Cattermole wrote:
> Apart from literature review type content, there isn't much to discuss here. There is nothing to tune.
> ....

What literature review type content would you be expecting?

If i say the earth is round, to I need to cite literature?

If i say private class attributes are an important, widely used component for enhancing encapsulation, and all the benefits that flow from that; do I need to cite litereature for this?

The very purpose of the idea for private(this) is to have an easier to use mechanism for having class attributes that are private to the class 'within' a module, and having those attributes enforced by the compiler.

I don't think anyone is going to argue that class-oriented oop does not greatly benefit from having class attributes that can be private to the class ;-)

So what would an argument against this idea be exactly?

That D already offers you a harder way to do it, and you should just accept that?

i.e never put other code in a module, if the module has a class in it.
and never put a unittest in that module either.
then...and only then.. is your problem solved.

No. A harder way to do it, ensures programmers will not do it, and may not even both to use D.

D needs an easier way.

Please..please... someone come up with a different argument against this idea.

But in regards to literature, this is interesting (especially the AHF findings):

https://www.researchgate.net/publication/2478145_Toward_the_Design_Quality_Evaluation_of_Object-Oriented_Software

On Friday, 26 April 2024 at 07:41:37 UTC, NotYouAgain wrote:
> On Thursday, 25 April 2024 at 13:35:29 UTC, Nick Treleaven wrote:
>> It should say whether __traits(getMember), allMembers and .tupleof can access private(this) members.
>>
>> private(this) maybe should be the default for synchronized classes.
>>
>
> Does that mean, that 'private(this)' would solve:
>
> https://issues.dlang.org/show_bug.cgi?id=23158

Yes, if synchronized class members are only allowed to be `private(this)`.

On 26/04/2024 11:36 PM, NotYouAgain wrote:
> On Thursday, 25 April 2024 at 05:53:18 UTC, Richard (Rikki) Andrew Cattermole wrote:
> 
>     Apart from literature review type content, there isn't much to
>     discuss here. There is nothing to tune. ....
> 
> What literature review type content would you be expecting?

Nothing for me personally.

But yourself or others might have something interesting to share!

On Friday, 26 April 2024 at 16:38:54 UTC, Steven Schveighoffer wrote:
> ..
> ...
> 1. unittests being able to examine/manipulate private data is *expected* and *desired*. How else do you plan to validate things are happening properly without having to expose more public functions than necessary? I'd expect a line such as `assert(c._count == 0);` to be a valid line in a unittest.
> 2. unittests generally are placed close to the things they test, and in fact are required to do so for documented unittests. This means they will be inside the class, and still have access to `private(this)` data.
>
> I don't find the arguments compelling enough to make this new feature. An entire module is as examinable as an entire class definition. It's already open in your editor even.
>
> -Steve

I don't agree with any of those propositions.

What value is there in allowing 'c._count == 0;' to be a valid part of a unittest when the class design implicitely (cause there is no explicit attribute available) makes c a private member to only be accessed through a public method?

You say 'An entire module is as examinable as an entire class definition.' - I say, that is exactly the problem that 'private(this)' can fix!

i.e. I want the class definition to be the class definition, and not the module definition to be the class definition.

At the moment, a class definition inside a module that contains other code in the same module, is about as useful as: int foo(T* p); "Is p an array? is foo() going to mutate what it points to? Is foo() going to free() it? How would I know without reading the implementation?" - Walter Bright.

It also makes the unittest in a module, an unreliable tool for testing - as you cannot rely upon the unittest to test what you think it should be testing.

Only in D, can a class definition mean something completely different when there is other code nearby. I'm not aware of any other language where the same applies.

It's worse than C++ friends. It's friendship galore... there is no way to control it inside a module, making classes difficult to reason about without taking into account all other code in the module. And using unittests in the same module as the class, as a tool for design verification tool, is just pointless - and prone to errors, as I've demonstrated - since the compiler cannot reason about the class intent either.

D is different to many well known languages, in that it stems from pragmatism more than theory. But ignoring type theory has consequences.

How can you reason about a class type, when that type has no means to control its own borders? Those borders are just as important 'inside' the module, as they are outside the module. This I think, is where any disagreement applies. All I'm asking for, is the tool to create those borders for use 'inside' the module.

You see it as a 'new' feature' I see it as a feature that should already be there.

There are clear benefits that arise from such a tool, as I've begun to demonstrate.

If you're saying these benefits are not real, I have to disagree.

On Friday, 26 April 2024 at 16:38:54 UTC, Steven Schveighoffer wrote:
>...
> module m;
>
> class C
> {
>    private(this) int _count;
>    public void setCount(int c) { _count = c; }
>
>    unittest
>    {
>       C c = new C();
>       c._count = 42; // oops, this is still allowed
>    }
> }
> ```

There is no 'oops' there.

The unittest is a member of the class!

It the unittest outside of the class that should not be allowed to compile.

On Friday, April 26, 2024 7:18:38 PM MDT zjh via dip.ideas wrote:
> On Friday, 26 April 2024 at 16:38:54 UTC, Steven Schveighoffer
>
> wrote:
> > I don't find the arguments compelling enough to make this new feature. An entire module is as examinable as an entire class definition. It's already open in your editor even.
> >
> > -Steve
>
> Although `the feature` is small,but  this feature is `harmless` and `many people` need it! Is this reason sufficient?

There is no question that some people want the feature, but a number of us do not buy the idea that anyone needs it. It adds further complication to the language (and personally, I don't want to see any more bugs related to visibility attributes), and the value that it adds is highly questionable.

For many of us, experience has shown that something like private(this) is completely unnecessary and that private as it works now is plenty. If a struct or class really needs to keep its data private from any other piece of code, it (or the other code) can be put into a separate module. And if a module is large enough that you have to be worried about whether code accesses a type's private members when you don't want it to, that module is arguably too large anyway.

Arguably, if someone feels the need for something like private(this), they're either doing something wrong, or they want it simply on the principle that types should be able to prevent all code that's external to them from accessing their private data. It really isn't an issue in practice, and if you really want to ensure that code can't access a type's private data, the workaround is simple.

What usually seems to happen with private is that most people who use D for any real length of time have no problem with how it works, whereas folks who are new to the language are sometimes initially confused and annoyed that it doesn't work the way that they wanted or expected. They usually expect that it would work like it did in whatever language they came from. So, they either want private changed, or they want something like private(this) added. Some people do continue to be annoyed about private long term, but most developers seem to learn that it's really not an issue, and they're fine with it.

If someone can come up with a particularly compelling argument such that it convinces Walter, then we may end up with private(this) (or something similar) at some point, but no one has yet come up with an argument that has convinced him that anything like it is necessary, and in general, the folks who have been around for a while tend to agree with him in this case.

Obviously, not everyone will agree, and we'll see what Walter says about this proposal, but based on what he has said about this issue over the years (including fairly recently), I would be very surprised if he decided to make any changes to private or accepted a feature proposal like private(this).

- Jonathan M Davis