Adding a new design constraint to D

[Dom Disc]

On Tuesday, 14 June 2022 at 10:47:18 UTC, forkit wrote:
> The decision to friend or unfriend should be a design 
> consideration, and not a design constraint enforced onto you by 
> the language.
>
> D has removed the need to use C++ like friend.

Yes, but it reached this by making the module the encapsulation 
unit.
If you want something to be a friend, put it in the same file.
If you want it to be no friend, put it in a different file.
If it's a member, you can do nothing about it - not with module 
level nor with class level privacy. Also not in C++ or Java or 
any other language I know about.

> Now I need a suitable, enforcable, design constraint, so i can 
> unfriend.

Yes, now we're talking. What we need is no new level of privacy, 
we need a method to unfriend something - especially applicable 
also to member functions. THIS would give us some real new 
benefit.

This could be realized by a new UDA (adding to the attribute 
soup): @noPrivateAccess or likewise. Add this to a function and 
the compiler will error out if you try to use any module private 
variable within this function.
The problem is: This may not be useful very often, because there 
may be a lot of private things, and you would like only some of 
them to be not accessible by this function. So you can add a list 
of variables that should not be usable: @noPrivateAccess(bla, 
blubb)
Now this becomes really ugly. Maybe vice versa would be better: 
give it a list of private stuff it is allowed to access: 
@limitPrivateAccess(x)
I would think this is the best solution, because most of the time 
a single function will need only access to very few private 
variables. Of course without annotation a function can access 
everything within the module as always, to not breaking any 
existing code.