| |
| Posted by Dom Disc in reply to forkit | PermalinkReply |
|
Dom Disc
Posted in reply to forkit
| 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.
|