Adding a new design constraint to D

[Abdulhaq]

On Tuesday, 14 June 2022 at 20:22:17 UTC, Dom Disc wrote:
> 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.

my mind is boggling LOL

seriously though, the access restrictions must be declared by the 
provider, to limit the notional consumer. Here the provider is 
restricting itself, it's pointless.