Adding a new design constraint to D

[forkit]

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.