On Tuesday, 14 June 2022 at 10:07:49 UTC, claptrap wrote:
>
> It leaves 99.9% of them going "Oh OK" and carrying on programming.
>

well.. it didn't take long for the passive-aggresive types to come out of the woodwork...now did it.

my argument clearly lays out why I believe it is useful.

your argument is, 'it's not important to us - because you (me) are just the 0.1% , and we're the 99.9%'.

I don't find that a credible argument worth considering any further.


>
> The argument is this... "If you have access to the source code of the module then you can already muck about with the internals of the class, you ought to know what you're doing so adding "strict private" doesn't actually gain you anything.
> 
> ...
>

the argument that I have access to the source file is a strawman, and will not be considered any further.

> It eliminates 99% of the need for it. The other 1% is a gift to the gods of compromise in exchange for friend access between classes that need it.
>

The decision to friend or unfriend should be a design consideration, and not a design constraint enforced onto you by the language.

D has removed the need to use C++ like friend.

Now I need a suitable, enforcable, design constraint, so i can unfriend.


>
> If "People coming from Java expect X" was a good argument for adding X then D would just be Java.
>

I don't know why Java always comes up??

I'm coming from C#.

In any case, C#, C++, Java, Swift..etc.. are arguably, one of the most widely used programming langauges in the world. The concept already exists across these languages. Millions of programmer already work with this concept (although apprarently it's not as clear cut in Java as one would expect).

What you're saying is, either these millions of programmers don't really need this feature, or they just don't need it in D. I cannot find the basis for either assertion in your response.


>
> The onus is on you to demonstrate a genuine need for it other than it's just what people expect.

I'm pretty sure that's exactly what I've done.

On Tuesday, 14 June 2022 at 10:21:34 UTC, The Zealot wrote:
>
> a) put the class in it's own module.
>

No you really can't and I already proved that with a couple examples in the other discussions on this topic; there are situations where you cannot do that, such as accessing private fields on a parent class using a sub class type within the parent class' module.

That's why the module-level private is a lie in D or at least incomplete.

On Tuesday, 14 June 2022 at 10:26:09 UTC, Paul Backus wrote:
>
> The main cost is the opportunity cost [1]. Any effort we spend implementing, documenting, debugging, and teaching 'private(scope)' reduces the amount of effort we can spend on other things. Likewise, any effort new users learning D have to spend on learning 'private(scope)' reduces the amount of effort they can spend learning other parts of the language (or, for that matter, using D to solve their problems).
>

you mean, like @mustuse ;-)

a 'new' feature that I'll likely *never* have a need to use btw.


> So the relevant questions here are:
>
> 1. Among all of the possible improvements we could make to D, is this particular one the *best* use of our limited resources, as a community?

You mean limited people working on the compiler?

So if I paid someone to cover all the work associated with this, you'd be ok with it?


> 2. Among all of the additional language features we could ask new users of D to learn, will this particular one give them the *most* benefit for their effort?
>
> [1] https://en.wikipedia.org/wiki/Opportunity_cost

again, I can come back to @mustuse ;-)

I can assure you, there is far more cognitive effort involved in understanding @mustuse, than there is for understanding the difference between 'private' and private(scope)'. For those of us who can already declare scope private, the cognitivie effort is.. 0.000000000000000000000001% of the cognitive effort needed to understand @mustuse.

On Tuesday, 14 June 2022 at 10:50:56 UTC, bauss wrote:
> On Tuesday, 14 June 2022 at 10:21:34 UTC, The Zealot wrote:
>>
>> a) put the class in it's own module.
>>
>
> No you really can't and I already proved that with a couple examples in the other discussions on this topic; there are situations where you cannot do that, such as accessing private fields on a parent class using a sub class type within the parent class' module.
>
> That's why the module-level private is a lie in D or at least incomplete.

The code you posted works exactly as it should. your function void handle(Bar child) does access the class Bar of another module, and the members of foo are not accessible.
and you can implement the desired behaviour like this:

import b;
void handle(Bar child) if(isDerivedFrom!(Foo, Bar))
{
  (cast(Foo)child)._c += child.c;
}

On Tuesday, 14 June 2022 at 10:54:17 UTC, forkit wrote:
> On Tuesday, 14 June 2022 at 10:26:09 UTC, Paul Backus wrote:
>>
>> The main cost is the opportunity cost [1]. Any effort we spend implementing, documenting, debugging, and teaching 'private(scope)' reduces the amount of effort we can spend on other things. Likewise, any effort new users learning D have to spend on learning 'private(scope)' reduces the amount of effort they can spend learning other parts of the language (or, for that matter, using D to solve their problems).
>>
>
> you mean, like @mustuse ;-)
>
> a 'new' feature that I'll likely *never* have a need to use btw.

Sure, you could make an argument that the effort spent on @mustuse could have been better spent elsewhere.

The main difference between @mustuse and private(scope) is that @mustuse was *impossible* to simulate using existing language features, whereas private(scope) can be simulated by extracting the relevant code into its own dedicated module. I understand that you have reasons for disliking this workaround, but the fact that a workaround exists is still relevant when determining what ought to be prioritized.

In any case, if you want to write a DIP, please don't let me stop you. The people you have to convince are Walter and Atila, not me.

On Tuesday, 14 June 2022 at 11:22:58 UTC, Paul Backus wrote:
> On Tuesday, 14 June 2022 at 10:54:17 UTC, forkit wrote:
>> On Tuesday, 14 June 2022 at 10:26:09 UTC, Paul Backus wrote:
>>>
>>> The main cost is the opportunity cost [1]. Any effort we spend implementing, documenting, debugging, and teaching 'private(scope)' reduces the amount of effort we can spend on other things. Likewise, any effort new users learning D have to spend on learning 'private(scope)' reduces the amount of effort they can spend learning other parts of the language (or, for that matter, using D to solve their problems).
>>>
>>
>> you mean, like @mustuse ;-)
>>
>> a 'new' feature that I'll likely *never* have a need to use btw.
>
> Sure, you could make an argument that the effort spent on @mustuse could have been better spent elsewhere.
>
> The main difference between @mustuse and private(scope) is that @mustuse was *impossible* to simulate using existing language features, whereas private(scope) can be simulated by extracting the relevant code into its own dedicated module. I understand that you have reasons for disliking this workaround, but the fact that a workaround exists is still relevant when determining what ought to be prioritized.
>

yes. so I covered this in my initial post:

---
"The next response, is that if you need this feature, then you can 'simulate it' by putting the class that needs this feature, into its own module.

However, the one-class-per-module approach, imposes its own new design constraint, and not one the programmer necessarily makes of his/her own volition.

It also does not necessarily follow, that a class in its own module, is there for the purposes of stipulating this constraint.

There are any number of a reason, why a class might be put into its own module. You cannot infer anything from that. You'd have to speak the designer to know intent."
---

> In any case, if you want to write a DIP, please don't let me stop you. The people you have to convince are Walter and Atila, not me.

I'm not at that stage yet.

I more interested in knowing what the others think about it.

I already know what 'core' think about it ;-)

> The main difference between @mustuse and private(scope) is that @mustuse was *impossible* to simulate using existing language features, whereas private(scope) can be simulated by extracting the relevant code into its own dedicated module. I understand that you have reasons for disliking this workaround, but the fact that a workaround exists is still relevant when determining what ought to be prioritized.

I don't think calling it a workaround is even correct.
_class private_ would actually be the workaround. Just to put multiple classes inside one file that should conceptually not be in the same file in the first place.

On Tuesday, 14 June 2022 at 11:04:55 UTC, The Zealot wrote:
> On Tuesday, 14 June 2022 at 10:50:56 UTC, bauss wrote:
>> On Tuesday, 14 June 2022 at 10:21:34 UTC, The Zealot wrote:
>>>
>>> a) put the class in it's own module.
>>>
>>
>> No you really can't and I already proved that with a couple examples in the other discussions on this topic; there are situations where you cannot do that, such as accessing private fields on a parent class using a sub class type within the parent class' module.
>>
>> That's why the module-level private is a lie in D or at least incomplete.
>
> The code you posted works exactly as it should. your function void handle(Bar child) does access the class Bar of another module, and the members of foo are not accessible.
> and you can implement the desired behaviour like this:
>
> import b;
> void handle(Bar child) if(isDerivedFrom!(Foo, Bar))
> {
>   (cast(Foo)child)._c += child.c;
> }

No it does not. You should never have to cast to a parent type, NEVER!

That is a red flag if you have to do that, a major one at that.

On Tuesday, 14 June 2022 at 10:50:56 UTC, bauss wrote:

> No you really can't and I already proved that with a couple examples in the other discussions on this topic; there are situations where you cannot do that, such as accessing private fields on a parent class using a sub class type within the parent class' module.

And Paul did show you how to do that with `child.Foo._c`.