Adding a new design constraint to D

[The Zealot]

On Tuesday, 21 June 2022 at 23:36:06 UTC, forkit wrote:
> On Tuesday, 21 June 2022 at 11:05:10 UTC, The Zealot wrote:
>>
>> you are always fast to dismiss any potential problems. Write a 
>> DIP. Add all possible ways in which adding _class private_ 
>> will affect/break existing code.
>> for starters: __traits(getVisibility), .tupleof, 
>> std.traits.hasMember, std.traits.hasStaticMember
>
> Well, I'd argue the opposite - i.e. that too many in the D 
> community are always fast to dismiss any potential problems.
>
> 'this is how we do it in D, so there!'
>
> 'our language doesn't need to give you that option. instead, 
> we'd rather force you into putting every class into its own 
> module.'.
>
> The vast majority of programmers have a different concept of 
> the class, to what D is wanting to **impose** on them.
>
> Can you even see the problem here?
>
> The problem is certainly NOT a result of wanting 'an option' to 
> make a member private within the specification of a class.
>
> You may retort.. I know you will ;-)
>
> // ----
>
> module test;
> @safe:
>
> class Base { private int x = 100; }
> class Derived : Base {}
>
> void main()
> {
>     import std.stdio : writeln;
>
>     Derived d = new Derived();
>     writeln(d.x); // this is so sad.
> }
>
> // ----

```
module test;
import std.stdio;

@safe:
interface IDerived {
     void fine() @safe;
}

IDerived createDerived() {
     static class Base { private int x = 100;  }
     static class Derived : Base, IDerived { void 
fine()@safe{writeln(x);} }
     return new Derived();
}

void main()
{
     import std.stdio : writeln;

     auto d = createDerived();
     d.fine();
     writeln(d.x); // look, no access.
}
```