Adding a new design constraint to D

[Dom Disc]

On Tuesday, 14 June 2022 at 19:39:40 UTC, Paul Backus wrote:
> If a function doesn't need access to private member variables, 
> don't implement it as a member function. Instead, put it in a 
> separate module and call it using UFCS.
Yes, that is nice.
But the most common usecase is that the class has multiple 
private variables, and each member function needs only access to 
some of them.
Today there is no way to express to which of them a function 
should have access and to which not.
My idea was the following:

class C
{
    private int _hidden_x;
    private int _hidden_y;
    @limitPrivateAccess(_hidden_x) foo(x)
    {
       _hidden_x = x;
       _hidden_y = 0; // error: foo has no access to _hidden_y
    }
}

So foo would normally have access to _hidden_y although the 
developer doesn't want that. That is so because today _all_ 
member functions (and friends) have access to _all_ private 
variables. The new UDA @limitPrivateAccess restrict this to only 
those private variables given as its parameters.
Together with a new privacy-level "@hidden" we could even have 
variables that no-one has access to, except those functions that 
are explicitly allowed to access them via the UDA. This would be 
the ultimate restriction level.