Adding a new design constraint to D

[bauss]

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

They're already broken today without class private.

Or at least .tupleof and hasMember is.

Depending on how it's added then it won't add any breakage to 
those as existing code will still yield the same results, it will 
only be for new code where there'll be a difference and arguably 
neither of those should return any class private members.

It should work just as it do today in theory.

The only difference will be in future apis exposed.

Example where nothing changes:

Today:

```
class Foo
{
   int x;
   int y;
}

// exposed: x,y
```

If class private existed:

```

class Foo
{
   int x;
   int y;
   hidden int z;
}

// exposed: x,y
```

Example where something changes:

Today:
```
class Foo
{
   int x;
   int y;
   int z;
}

// exposed: x,y,z
```

If class private existed:

```
class Foo
{
   int x;
   int y;
   hidden int z;
}

// exposed: x,y
// breaking change in this case only
// clearly you would mark this as a breaking change in the new 
release
// that is not a problem for libraries and/or user code - it's 
only a problem for ex. phobos
// arguably phobos would just never change anything to class 
private
```