On Friday, 26 January 2024 at 23:41:51 UTC, FairEnough wrote:
> On Thursday, 25 January 2024 at 00:19:54 UTC, Jordan Wilson wrote:
>>
>> ...
>> That wasn't what was said. What was said was "causing US problems". I.e. on the whole, the lack of class-level privacy does not appear to be causing widespread problems, which implies that it's simply lower on the list of feature requests for most people.
>>
>
> Allowing mutable state to escape - the confines of the type in which it has been declared - into the whole of the module, will inevitably lead to a problem.
>
> My first use of the D language demonstrated that this statement is factual.

When I first used a dynamically typed language, I was inevitably caught out by type errors. I understood this to be part of the many trade offs all languages make.

> The more 'widespread' D is used, will 'likely' also demonstrate the same.

I suspect the proportion of users that really care about explicit class privacy and find the workaround of putting a class that needs such privacy into a separate file untenable, will remain the same.

Jordan

On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson wrote:
>
> ...
> I suspect the proportion of users that really care about explicit class privacy and find the workaround of putting a class that needs such privacy into a separate file untenable, will remain the same.
>
> Jordan

Well D already has class privacy. Would be absurd if it didn't.

So this is not about class privacy per se, nor is it about OOP.

It's about whether D should provide an *option* for class privacy within a module, so that the programmer can use it when it is appropriate (e.g. there is other code in the module as well, perhaps even just a unittest, and the programmer wants the compiler to enforce type safe use of that type within that unittest).

But still none of what you said addresses the questions I put forward. Answers to those questions will form the basis for a need (or not), for private(this).

(Q1) Are there any circumstances where a class type might need to retain control over its state from other code within the same module (including unittest code)?

(Q2) What problems could potentially occur when a class types state is always leaked into the module.

If your answer to Q1 is no, then there is nothing more to say.

If your answer to Q1 is yes, but in this case just put the type in its own module, then you've not really answered the question, since there would be no other code in the module.

If your answer to Q2 is none, then there is nothing more to say.

If your answer to Q2 identifies one or potential problems, you have an immediate type safety concern that needs to be addressed, somehow. There is no language feature to help you deal with that problem (i.e have the compiler enforce your design). You simply have to avoid putting any other code in the same module (this includes your unittest code).

So D's approach to answering these two questions, is you should prevent the circumstance from ever arising by constraining your design to one type per module, and the unittest for that type in its own separate module as well. That will be acceptable to some, and not others.

It also raises a final question of whether that is all the D programming language should ever provide to the programmer - a way to avoid these situations by constraining your design.

If you answer yes, there is obviously nothing more to discuss.

If you answer no, then what can be done about it?

As I've mentioned, I think Swift got the balance right.

On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson wrote:
> ..
> When I first used a dynamically typed language, I was inevitably caught out by type errors. I understood this to be part of the many trade offs all languages make.
>

Yes, but a big bank would not write its financial applications in a dynamically typed language, now would it.

In any large complex application, type safety is paramount.

D came about as a reaction to C/C++

Same for Swift.

Same for Go.

But since Go doesn't have a class type, its pointless comparing implementation between Go and D.

Much better to compare D and Swift in this regards.

There will be some who say 'D did it right', and others who say 'but Swift did it better'.

It may depend on the priority a programmer gives to type safety, as to which side they are on.

Personally, I don't like being 'caught out by type errors' ;-)

On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson wrote:
> ..
> I suspect the proportion of users that really care about explicit class privacy and find the workaround of putting a class that needs such privacy into a separate file untenable, will remain the same.
>
> Jordan

Or ...they might just add it to a fork of D.


"[PR ready] Class-level private (in addition to the current module-level private)"

https://dpldocs.info/opend/roadmap.html

On Saturday, 27 January 2024 at 11:17:53 UTC, FairEnough wrote:
> On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson wrote:
>> ..
>> I suspect the proportion of users that really care about explicit class privacy and find the workaround of putting a class that needs such privacy into a separate file untenable, will remain the same.
>>
>> Jordan
>
> Or ...they might just add it to a fork of D.
>
>
> "[PR ready] Class-level private (in addition to the current module-level private)"
>
> https://dpldocs.info/opend/roadmap.html

I thought you already has fork with this feature enabled.

On Saturday, 27 January 2024 at 10:42:26 UTC, FairEnough wrote:
> On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson wrote:
>>
>> ...
>> I suspect the proportion of users that really care about explicit class privacy and find the workaround of putting a class that needs such privacy into a separate file untenable, will remain the same.
>>
>> Jordan
>
> Well D already has class privacy. Would be absurd if it didn't.

I said "explicit class privacy", I was meaning the concept you are talking about (it probably wasn't the most accurate phrase).

> But still none of what you said addresses the questions I put forward. Answers to those questions will form the basis for a need (or not), for private(this).

By offering counter questions, I was trying to make a point about the line of questioning itself. But I'll answer anyway.

> (Q1) Are there any circumstances where a class type might need to retain control over its state from other code within the same module (including unittest code)?

I have not come across such a circumstance personally, during my time with languages using higher level encapsulation (D module / Go packages). I can certainly imagine that some would have that need for a particular situation, but I can't think of it.

I believe we are now in the "there is nothing more to be said" territory (just for the record, I think we both agree the feature is good, I just don't think the feature is necessary at all...nice-to-have at best. I suspect we'll agree to disagree).

Jordan

On Friday, 26 January 2024 at 23:41:51 UTC, FairEnough wrote:
> On Thursday, 25 January 2024 at 00:19:54 UTC, Jordan Wilson wrote:
>>
>> ...
>> That wasn't what was said. What was said was "causing US problems". I.e. on the whole, the lack of class-level privacy does not appear to be causing widespread problems, which implies that it's simply lower on the list of feature requests for most people.
>>
>
> Allowing mutable state to escape - the confines of the type in which it has been declared - into the whole of the module, will inevitably lead to a problem.
>
> My first use of the D language demonstrated that this statement is factual.
>
> The more 'widespread' D is used, will 'likely' also demonstrate the same.

What we need to do is find a way to make the computer explode when somebody does that. Weed out the stupid programmers. ;-)

On Saturday, 27 January 2024 at 19:58:55 UTC, Jordan Wilson wrote:
> On Saturday, 27 January 2024 at 10:42:26 UTC, FairEnough wrote:
>> On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson
>>
> I believe we are now in the "there is nothing more to be said" territory (just for the record, I think we both agree the feature is good, I just don't think the feature is necessary at all...nice-to-have at best. I suspect we'll agree to disagree).

Its probably more useful if you manage a team of barely competent idiot programmers.

On Saturday, 27 January 2024 at 11:42:59 UTC, Sergey wrote:
> On Saturday, 27 January 2024 at 11:17:53 UTC, FairEnough wrote:
>> On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson wrote:
>>> ..
>>> I suspect the proportion of users that really care about explicit class privacy and find the workaround of putting a class that needs such privacy into a separate file untenable, will remain the same.
>>>
>>> Jordan
>>
>> Or ...they might just add it to a fork of D.
>>
>>
>> "[PR ready] Class-level private (in addition to the current module-level private)"
>>
>> https://dpldocs.info/opend/roadmap.html
>
> I thought you already has fork with this feature enabled.

I integrated these changes into my own fork a long time ago: https://github.com/dlang/dmd/compare/master...dkorpel:dmd:private-this#diff-8da4a723a20020bf5d1edf1a9f1344eb776c73a0ae35ccee95d3bc24cb0600a7R242

I've never looked back, and never had any issue with this feature. It's just works.

I prefer to design my class upfront so that it doesn't leak private mutable state. Not outside of the module, and not inside of the module.

But should I ever need to leak mutable state into the module, I can do that as well.

So I have the best of both worlds. Others don't have that, but I do ;-)