On Sunday, 19 June 2022 at 08:12:28 UTC, forkit wrote:
> On Saturday, 18 June 2022 at 05:50:56 UTC, Walter Bright wrote:
>>
> What is the rationale?

Just leave it here, to be sure, that every participant of the thread have seen this:

https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/

On Sunday, 19 June 2022 at 09:46:40 UTC, Sergey wrote:
> On Sunday, 19 June 2022 at 08:12:28 UTC, forkit wrote:
>> On Saturday, 18 June 2022 at 05:50:56 UTC, Walter Bright wrote:
>>>
>> What is the rationale?
>
> Just leave it here, to be sure, that every participant of the thread have seen this:
>
> https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/

So am aware of this article, of course.

It explains why 'everything is global' in a module - in essence, to be able to encapsulate classes and 'free' functions in the one place, and thereby avoid the need to have C++ like 'friend'.

Fine. I don't reject that argument.

What I reject (and what the article does not address), is not having an 'option' to 'unfriend'. What is the rationale for that?

Not having that option, means you cannot restrict access to an object through the set of operations as specified by that type. That means, you've lost the essential capacity for using the class as a means of data abstraction.

In D, the class is not a data abstraction anymore. It's just one 'thing' in the larger module abstraction.

As I've said before, in D, you cannot put "wtf" into an int. The int is a data abstraction with defined invariants that the compiler will enforce.

I just wanted an option, so that my class type could have its invariants explicately declared, and  enforced by the compiler, and not have to worry, that someday, someone, maybe even me, might end up putting "wtf" into my int.

On Sunday, 19 June 2022 at 10:11:10 UTC, forkit wrote:
>

I wonder if D should have shown even more inconsistency here, and instead of calling the class a 'class', called it 'doWhatEverTheFu#%YouWantWithMe'.

On Sunday, 19 June 2022 at 09:46:40 UTC, Sergey wrote:
> On Sunday, 19 June 2022 at 08:12:28 UTC, forkit wrote:
>> On Saturday, 18 June 2022 at 05:50:56 UTC, Walter Bright wrote:
>>>
>> What is the rationale?
>
> Just leave it here, to be sure, that every participant of the thread have seen this:
>
> https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/

And the nonsensical debates like https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/#comment-6546 wouldn't have happened, if D had done the most reasonable thing from the start - make 'private' mean 'private to the current scope'; provide 'private(ancestor)' for choosing the encapsulation boundary; and maybe provide shortcuts for module and package. That's it. No need for articles trying to justify the arbitrary imposition.

On Sunday, 19 June 2022 at 11:19:43 UTC, Max Samukha wrote:
>
> ...
> And the nonsensical debates like https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/#comment-6546 wouldn't have happened, if D had done the most reasonable thing from the start - make 'private' mean 'private to the current scope'; provide 'private(ancestor)' for choosing the encapsulation boundary; and maybe provide shortcuts for module and package. That's it. No need for articles trying to justify the arbitrary imposition.

Additionally, in the comments of that article, Jim Balter uses the Ceylon Language in his argument against the idea of allowing scope level privacy within a module.

But looking at the Ceylon Language docs, I see they already made the argument for me ;-)

"Of course, we could have chosen to make shared visibility the default, providing a private annotation to restrict access. But that would have been very harmful to modularity, a key goal of the language.

The "best" default is the most restrictive option. Otherwise, the developer of a module might accidently make something shared that they don't intend to make shared, and be forced to either continue to support the unintentionally-shared operation for the rest of the life of the module, or break clients. There would be nothing the compiler could do to warn you when you accidently left off a private annotation."

https://ceylon-lang.org/documentation/1.2/faq/language-design/

On Sunday, 19 June 2022 at 22:45:44 UTC, forkit wrote:
>

I'm happy (more than happy actually) to conclude my input into this discusssion with this:

D has, by design, rendereed meaningless the concept of a private class member (by not even allowing you to declare one as being private!).

So, what happens when you do this?

Well, Stroustrup provided some insight into the problem this would likely cause.. a looooonnngggg..... time ago...:

(NOTE: below he discusses this in the context of inheritance, not modules):

"A member of a derived class has no special permission to access private members of its base class ..
This comes as a surprise to some, but consider the alternative: that a member function of a derived class could access the private members of its base class. The concept of a private member would be rendered meaningless by allowing a programmer to gain access to the private part of a class simply by deriving a new class from it. Furthermore, one could no longer find all uses of a private name by looking at the functions declared as members and friends of that class. One would have to examine every source file of the complete program for derived classes, then examine every function of those classes, then find every class derived from those classes, etc. This is, at best, tedious and often impractical." - Section 12.2.1 - The C++ Programming Language, 3rd Ed. Stroustrup 1997.

In relation to D, the problem is this:

D does not use friend declarations. In essence, everything declared in the module is a friend of any class declared within that module.

In D, you have no say in this (i.e. it provides no language mechanism to decalre a private member of a class.)

So not only has D rendered meaningless the concept of a private class member, it's also makes it impossible to know the friends of a class by looking at the
class definition, for its friends.

In essence, you must examine **all** code within a module **manually** before you can understand anything about the class.

The class type in D, has been (intentionally!!) morphed into a 'doWhatEverTheFu#$YouWantWithMe' type.

You can of course cast this 'doWhatEverTheFu#$YouWantWithMe' type back into a kinda class type, by putting it in its own module.

Then can be no justification for this. It simply must be fixed, before one can take D seriously, as being a language where you can do OOP.

The class type is not a type that should be open to this abuse.