On Tuesday, 28 June 2022 at 16:06:54 UTC, Daniel N wrote:
>
> Yes, but I know Walter, he mentioned many times his dislike for compiler switches and warnings and he raised some very good points, which I partially agree with, but his dislike of switches is even stronger than mine.
>

Well. In this case, Walter is right ;-)


> Imagine four innocent small switches -A -B -C -D, if you can toggle all of these the result is a combinatorial explosion, because some bugs might only manifest in certain combinations and thus the required testing time increases greatly.
>

That's why I would not accept the -fe thing you mention.

The correctness of my unittest should not depend on whether i remember to use a specific compiler switch.

> If "we" make our own tools with stricter warnings that can be tuned to everyones individual preference, there is 0 risk of compiler regressions.

There is a case to be made, for a linter, obviously.

I disagree strongly, that a linter should be used to verify the encapsulation of a class (in terms of what something like private(this) would do.)

This is not a 'personal preference'. I wish people would stop using that argument against the idea. The ability to selectively make member variables private to the class, is something millions of programmers have at their finger tips everyday, and have had it, for decades!

The principle of information hiding, is at the core of good programming practice.

Indeed, everything in a module is pretty much hiding something. I just cannot fathom why a programming language would not have an option to do that explicately for a class type. I've never heard an argument that makes even the slightest sense to me.

I do feel sad, that I cannot promote D over here in Australia, because it just fails to recognise the importance of this, in the life of millions of programmers.

It's an established idiom, that you cannot do in D. It's really sad. That code I presented is why I still don't use classes in D, even after using D for almost 7 years now.

Instead, people seem more interested in '=>' than encapsulation ??

On Tuesday, 28 June 2022 at 20:29:27 UTC, forkit wrote:
> On Tuesday, 28 June 2022 at 16:06:54 UTC, Daniel N wrote:
>>
> The correctness of my unittest should not depend on whether i remember to use a specific compiler switch.
>

But what if your favourite editor automatically highlighted the entire line with red?

>
> This is not a 'personal preference'. I wish people would stop using that argument against the idea.

After being exposed to D, I usually end up trying to emulate it when I am forced to work in other languages. For this reason some of my C++ files are filled with 20+ friend declarations just so I can do what I want inside that file...

Some people hate goto and some love it.

On Tuesday, 28 June 2022 at 20:58:56 UTC, Daniel N wrote:
>
> But what if your favourite editor automatically highlighted the entire line with red?
>

my favourite editor, is the one I wrote myself ;-)

>
> After being exposed to D, I usually end up trying to emulate it when I am forced to work in other languages. For this reason some of my C++ files are filled with 20+ friend declarations just so I can do what I want inside that file...
>

But C++ gives *you* a choice right?

I'm not sure continuing to compare D to C++ is all that benefical anymore.

I'd recommend you have a look at Swift. Then try comparing D to Swift, and you will come to very different conclusions.


> Some people hate goto and some love it.

Again, *you* can choose to use goto, or not.

You *cannot* chose to 'explicately' declare private members, within the class itself. D has made the design choice for you. The are pros and cons for that decision. But the biggest con, is that this choice has been completely eliminated from the language.

You have that choice, in C++, C#, Java (erhh!), Swift, Javascript.......

Those languages represent a pretty big portion of programmers worldwide - who may or may not use private member variable in their day to day tasks, but they all have the choice to do so, or not.

There's really no 'nice' way to frame this. Removing 'choice' for this very substantial idiom, is one of D's biggest design failures IMO. (yes, others have a different opinion, which of course is just fine. This is just mine).

I cannot use classes in a language where I have to **constantly** write notes in the code, just to remind myself, and others, to use the public interface, and not directly read/mutate a private member.

Again, that mistake I initially made in the unittest of that unsafeVector code I put in my post, was a *genuine* mistake I made only yesterday!

I don't know what the solution to that is. Put every unittest of a class in its own module perhaps?

On Tuesday, 28 June 2022 at 20:58:56 UTC, Daniel N wrote:
>

I'm reading a thesis at the moment, and I was just struck by this statement:

"the price of enabling cooperative interaction is that destructive interference is enabled as well."

Without something like private(this), hazardous interactions are inevitable, and will increase with scale (e.g. having 20+ friend functions in your class ;-)

Of course useless isolation is not ideal either.

Another quote from the thesis:

"As language and system designers, our goal is to help programmers move into the upper right corner, where the interactions needed for cooperation are enabled while minimizing the extent to which problematic interactions are thereby also enabled."

That is precisely what private(this) could help facilitate.

On Tuesday, 28 June 2022 at 22:03:54 UTC, forkit wrote:
> On Tuesday, 28 June 2022 at 20:58:56 UTC, Daniel N wrote:
>>
> Without something like private(this), hazardous interactions are inevitable, and will increase with scale (e.g. having 20+ friend functions in your class ;-)

this is just not true. don't put the damm class in module scope if you don't want it accessible.
It's just your unwillingness to adjust your programming to the language that causes these problems. The language offers enough tools to deal with it, you just don't accept them as valid, because you are used to _your perceived correct way of proper encapsulation_.

In reality the encapsulation boder is totally arbitrary. And you have failed to even give one _real world_ example of a bug it would have prevented.
In reality, noone is randomly accessing private state. It's a non issue in languages that don't have the feature.

And im most cases i'd argue that private(this) would actually enurage bad code design, so there is reason not to have it, like goto.

Anyway, feel free to write a linter, i'm sure there are other people who would apreciate it.

On Thursday, 30 June 2022 at 11:36:01 UTC, The Zealot wrote:
> On Tuesday, 28 June 2022 at 22:03:54 UTC, forkit wrote:
>> On Tuesday, 28 June 2022 at 20:58:56 UTC, Daniel N wrote:
>>>
>> Without something like private(this), hazardous interactions are inevitable, and will increase with scale (e.g. having 20+ friend functions in your class ;-)
>
> this is just not true. don't put the damm class in module scope if you don't want it accessible.
>

Don't put @nogc, just stop GC allocations yourself.

On Thursday, 30 June 2022 at 11:37:30 UTC, bauss wrote:
> On Thursday, 30 June 2022 at 11:36:01 UTC, The Zealot wrote:
>> On Tuesday, 28 June 2022 at 22:03:54 UTC, forkit wrote:
>>> On Tuesday, 28 June 2022 at 20:58:56 UTC, Daniel N wrote:
>>>>
>>> Without something like private(this), hazardous interactions are inevitable, and will increase with scale (e.g. having 20+ friend functions in your class ;-)
>>
>> this is just not true. don't put the damm class in module scope if you don't want it accessible.
>>
>
> Don't put @nogc, just stop GC allocations yourself.

you can do that without @nogc ;) don't link in the GC.
But my point is you _should not_ put the class in module scope in the first place, it doen't belong there. if it has private parts, it is an implementation detail and should not be visible at all, but an _interface_ should be used. and if you need inheritance, it _should_ be placed in it's own module.

e.g.
```
interface Foo {
}
Foo fn() {
   static class Bar : Foo { int private_x; } // private_x access is limited to fn() scope
   return new Bar ();
}
```

On Thursday, 30 June 2022 at 14:55:47 UTC, The Zealot wrote:

> e.g.
> ```
> interface Foo {
> }
> Foo fn() {
>    static class Bar : Foo { int private_x; } // private_x access is limited to fn() scope
>    return new Bar ();
> }
> ```

A way to success: impose an unnatural level of encapsulation and then offer a bunch of ugly kludges to work around that.