Non-transitive immutable? Read only struct.

[Gregor Mückl]

On Thursday, 5 December 2019 at 17:01:07 UTC, Ola Fosheim Grøstad 
wrote:
> So, I get it, head-const has been discussed to death before. 
> But it seems to me that it is more of a problem that there is 
> no (to my awareness) non-transitive immutable. If there is, I 
> apologize.
>
> So, there are at least 4 situations where you really want that:
>
> 1. Protect fields in structs/classes after initialization. 
> Reduces bugs. Documents intent.
>
> 2. Turn received values from functions into something that 
> cannot be modified reliably irrespective of what the protection 
> the called function has set for it. Reduces bugs.
>
> 3. To have sensible immutable tuples that can point to 
> non-immutable things. In my view, a must have.
>
> 4. To have structures in ROM that can point to memory mapped 
> registers or RAM. Not a must have, but sensible.
>
> I'm not saying that immutable should change, but that there is 
> need for something in addition to that. Call it "readonly" if 
> you want.

Can you clarify how this goes beyond the classic OO pattern of 
private member variables with public getters and no setters? If 
there was a class-private visibility, D could emulate everything 
except point 3 on your list, I think, albeit somewhat verbosely. 
So how is your thinking diverging from that?