`restricted` member variables

[deadalnix]

On Monday, 20 June 2022 at 15:49:20 UTC, Paul Backus wrote:
> On Monday, 20 June 2022 at 11:04:16 UTC, Mike Parker wrote:
>> From that perspective, I see massive gaping hole here. I've 
>> done a complete 180 on need for further restricting member 
>> variable access. But I'm seeing it more granularly than 
>> class-level and down to the function level.
>>
>> After some spitballing, here's something I like:
>>
>> ```d
>> class E
>> {
>>    restricted int _y;
>>    restricted(_y) void y(int newY) { _y = newY; }
>> }
>> ```
>
> This is very similar in concept to `@system` variables, except 
> instead of a single `@system`/`@trusted` attribute pair, you 
> have individual `@trusted`-like attributes for each specific 
> variable.
>
> For comparison:
>
> ```d
> class E
> {
>     @system int _y;
>     @trusted void y(int newY) { _y = newY; }
> }
> ```
>
> I'm not convinced the extra granularity is worth adding an 
> entire new attribute for.

No.

Clearly D has a problem with "a problem => an attribute".

But more importantly, the use of data in a class should be 
strongly cohesive - as in most method should use most of the 
fields overall. When that's not the case, it's a strong sign that 
you actually have two class in there, you just bundled them into 
one.

This feature can only be used in a meaningful way in classes that 
are structured ass backward.