`restricted` member variables

[Mike Parker]

On Thursday, 23 June 2022 at 01:19:11 UTC, forkit wrote:
> On Thursday, 23 June 2022 at 01:13:22 UTC, forkit wrote:
>>
>> ...
>> In D, the `invariant` feature allows you to maintain the 
>> invariants of any class from within the class.
>> ..
>
> On re-reading that part again, I'm confused as to what it means.
>
> What is this 'invariant' feature you mention?

https://dlang.org/spec/class.html#invariants

A class in its own module can fully maintain its invariants, even 
when multiple methods modify a variable. Every function call is 
bookended with the invariant check.

There's a hole in module scope in that we treat modules as part 
of the aggregate's private API, but not as part of the public 
API. A new level of protection wouldn't fully plug that hole, but 
running invariant checks on access to private member variables 
from within the module would.

This whole discussion has led me to the opinion that if a module 
is part of the private API, then we ought to be treating it as 
part of the public API in terms of invariant and synchronized.