Adding a new design constraint to D

[forkit]

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.
}

// ----