`restricted` member variables

[The Zealot]

On Tuesday, 21 June 2022 at 02:05:22 UTC, deadalnix wrote:
> On Tuesday, 21 June 2022 at 01:20:27 UTC, Mike Parker wrote:
>> On Tuesday, 21 June 2022 at 01:17:14 UTC, Mike Parker wrote:
>>> [...]
>>
>> That said, spilling class internals out into a separate module 
>> is a bit "icky". Targeted invariants would be nice. Not a must 
>> have, probably a niche case, but definitely nice to have.
>
> No, you don't spill the struct internal, in fact you don't need 
> to spill anything specific to the struct. What you want to 
> spill is the restricted write mechanism so if goes through a 
> validation step.
>
> This can all be done in a template and provided as this for the 
> whole application to use any time someone wants a restricted 
> field.
>
> That being said, the invariant really doesn't trigger in a way 
> that is consistent with the other rules of the language, so 
> there is something there.
>
> IMO the ivnariant has two problems (one of them I opened a bug 
> repport for, but idk what happened to it):
> 1/ It need to trigger for anything that touches the class's 
> privates parts, not just members.
> 2/ Code that trigger the invariant must not call it again down 
> the road, as this tends to cause infinite recursions and/or 
> trigger the invariant mid transform at a time the object might 
> not be valid (and therefore fail the invariant check) even 
> though at no point any external observer can see object in an 
> invalid state.

+1
i absolutely agree with this.
if anything, i'd like to see more control over when invariants 
are actually checked.

something like
```
invariant(default)
     {
         assert(1 <= day && day <= 31);
         assert(0 <= hour && hour < 24);
     }
invariant(always) {
         assert(1 <= sec && sec <= 60);
}
```