`restricted` member variables

[deadalnix]

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:
>> On Tuesday, 21 June 2022 at 01:01:09 UTC, deadalnix wrote:
>>
>>> I'm pretty sure x can be encapsulated in some struct here.
>>
>> Yes, I did note that later in the post you just replied to :-) 
>> Put it in a struct and then a different module. So 
>> `restricted` is absolutely pointless because of that. It's the 
>> obvious solution that I overlooked until I read your comment 
>> about two classes bundled in one.
>
> 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.