Adding a new design constraint to D

[Timon Gehr]

On 15.06.22 12:57, Abdulhaq wrote:
> 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.

It's not pointless. It's automatically checked code documentation. There 
are surprisingly many vocal programmers who argue as if they never wrote 
software in a team (possibly with turnover).