Adding a new design constraint to D

The Zealot zod at zod.zod
Tue Jun 14 10:21:34 UTC 2022


"but the example, is the kind of code I, and many like me, will 
come to D and write, expecting that private means private to the 
scope of the class."
That is a _you_ problem though. D ist different to other 
languages, you cannot except it to have all the features, or for 
features to behave the same way as other languages.

Now you can solve the 'problem' of not having _class private_ two 
ways already.
a) put the class in it's own module.
b) put the class decleration inside a function and use an 
interface declared at module scope.

In addition, _class private_ doesn't even solve the encapsulation 
'problem' in the first place.
All member functions could still access all private class 
members. Consider the following:
```
class Foo {
class_private int _a;
void setA(int v) { _a = v < 42 ? v : 42; }
void oh_no() { _a = 666; /*fail!!*/ }
}
```

IMHO, _class private_ doesn't add any _value_ whatsoever, and it 
complicates metaprogramming.




More information about the Digitalmars-d mailing list