On Saturday, 27 April 2024 at 05:44:15 UTC, NotYouAgain wrote:
> On Saturday, 27 April 2024 at 01:41:54 UTC, Jonathan M Davis wrote:
>>..
>> ...
>> - Jonathan M Davis
>
> As usual, the only solution you can provide to the problems that I've very clear outline, are put the class in it's own module.

Yes, that's the solution. It works right now. Adding a feature to the language requires justifying its cost, and I haven't seen anything in this thread that does, *especially* since the user always has the option of creating a module for every class if they so wish.

On Tuesday, 30 April 2024 at 00:01:00 UTC, NotYouAgain wrote:
> The source of all this, can be trace back to the D designer who decided to change the "right and obvious" meaning of private.
>
> That was a mistake. It's not that the module private is wrong, that certainly has a place, but changing the meaning of private, was a mistake that D has to live with.

It's not "wrong". It's just a different philosophy, like with transitive const.
You can claim something is "logical const" but still modify internal state, or you enforce that something that is claimed const can really not be modified whatsoever.
Neither of the two is "wrong", it's just different and you can not easily translate between the two.
With private you can claim something is not accessed by other stuff within the same file (by declaring it "private to the class"), but this is only "logical private", because effectively if you have access to a file, you can access everything in that file, no matter how "private" it is.
But if something is in a different file, you can enforce that someone cannot access (aka modify) what is in there. Maybe simply by making the file readonly, but there are also stronger protection measures possible.

As I said in the other thread: A black-box test (for example something that tests the encapsulation of an object) shall not have the possibility to modify the object under test. So it cannot be in the same file. If you implement it in the same file and claim privacy, you are lying to yourself. It is simply not true.

In both cases (const and private) C++ allows the programmer to lie to himself (which is convenient, I confess) and D enforce correct behaviour (which is inconvenient at times).
I prefer the D philosophy.

I have nothing against private(this), it's convenient, you are right.
But I hate it if someone insist to call the other philosophy "wrong". That is what provoces so much resistence in these threads. Your chances to get the feature you want so much will become much higher, if you refreign from insulting others.

I've refrained so far from deleting any posts in this thread that still had on-topic content. However, I've had to delete several now, and I've had enough complaints about the tenor of this thread that I can declare it's been disruptive, so let's shut it down here.

Given Atila's comment, the idea doesn't have a chance of approval anyway. If anyone wants to submit a DIP for it, feel free. But if you do it, you're pretty much tilting at windmills.

I welcome anyone who wants to discuss the idea civilly to start a new thread.

On Tuesday, May 21, 2024 3:50:38 AM MDT Quirin Schroll via dip.ideas wrote:
> On Saturday, 27 April 2024 at 07:39:19 UTC, Jonathan M Davis
>
> wrote:
> > (particularly since the change from private, public, etc. being protection attributes to visibility attributes seems to have been tricky enough that a number of subtle bugs were introduced in the process).
>
> I know this is slightly off-topic, but I have two questions about
> that:
> 1. When did this happen? I don’t need an exact date, but before
> 2015 and after 2015 would be helpful to me because I started
> learning D end of 2015 and so I could know if I ever used D with
> the old “protection attributes” way.

It was DIP 22:

https://github.com/dlang/DIPs/blob/master/DIPs/archive/DIP22.md

It looks like the original changes were merged in 2016.

> 2. What is the difference? I don’t need details, maybe a single example does the job.

Before DIP 22, functions which the code did not have access to (e.g. a private function in another module) were considered to be part of the overload set but then resulted in an error when a function which the calling code didn't have access to was the best match. This meant that simply adding a private function to your module could break someone else's code if it happened to be a better match for the arguments than the overload that they'd been using. E.G. maybe they had a function foo(long), and you added a private foo(int) to a module that they imported, then any calls to foo with integer literals - like foo(42) - would suddenly try to call your function instead of theirs, resulting in an error, since it was private.

After DIP 22, functions which the code does not have access to are not considered part of the overload set. So, if you have multiple functions with the same name which could match, a function which that code does not have access to will no longer result in an error. Instead, you'll get the best match out of the functions that you actually have access to. So, adding a private foo(int) to your module won't suddenly result in foo(42) trying to call your foo instead of the foo(long) that the code was already using.

So before, private, public, etc. were protection modifiers / attributes, and now they're visibility modifiers / attributes, since before, they controlled whether you had access to a symbol, whereas now, they control whether that symbol is visible. You can still get at the private stuff via traits, but otherwise (barring compiler bugs), the private symbols don't exist for modules that import that module, and you won't get breakage just because the list of private symbols in a module that you're importing changes.

- Jonathan M Davis