`restricted` member variables

[Mike Parker]

On Monday, 20 June 2022 at 11:59:05 UTC, Kagamin wrote:
> On Monday, 20 June 2022 at 11:04:16 UTC, Mike Parker wrote:
>> but then what's the point if it's so easily broken from 
>> elsewhere in the module?
>
> You seemingly ask for a puristic language. But what's the point 
> of a puristic language? Why do you think it's better than a 
> practical language?

Uh, no. This isn't about purity. I don't care about it in the 
absence of invariant, synchronized, and function contracts. And 
I'd be happy with fixing simply fixing the invariant/synchronized 
hole by triggering them on member variable accesses. That would 
be preferable to adding a new feature.

That said, I like the idea of going one step further in the case 
of contracts and, as I mentioned, allow cases where you can treat 
a contract like a single-function invariant by restricting member 
variable access to a specific set of functions. I put this out 
there to see if anyone else likes it, and to discuss if a feature 
like this is worth the added complexity.