`restricted` member variables

[Ola Fosheim Grøstad]

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?

Well, class invariants require full encapsulation.

Either way, the proposed solution won't work, because you only 
want to check the invariant when you exit "the penetration of the 
object capsule".

It is perfectly ok that the invariant is broken once you are 
inside the "object capsule method". It is only when you leave the 
initial method that "entered the object capsule" that the 
invariant should be checked.

Methods are clear gateways, free standing functions are not.