Adding a new design constraint to D

[The Zealot]

On Thursday, 16 June 2022 at 11:40:16 UTC, forkit wrote:
> On Thursday, 16 June 2022 at 11:31:48 UTC, Ola Fosheim Grøstad 
> wrote:
>> On Thursday, 16 June 2022 at 11:26:23 UTC, forkit wrote:
>>> [...]
>>
>> I think I have, but I can do it again:
>>
>> Since D has meta programming capabilities it can affect meta 
>> programming code that makes assumptions about access control 
>> modes being fixed to the existing set.
>>
>> As such it will be a breaking change, but will probably not 
>> break most programs.
>>
>> (Basically all changes that go beyond syntax sugar are 
>> breaking changes in D.)
>
> ok, except you too ;-)
>
> I must have missed this in all the nonsense going on...
>
> the constraint is optional, just as using meta programming is 
> optional.
>
> but if the D language requires that 'meta programming in D must 
> be able to access class members that are private to the scope 
> of the class', then assuming this would not be the case if the 
> suggestion were implemented, then we have a first, genuine, 
> issue to consider  ;-)

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