Challenge: write a reference counted slice that works as much as possible like a built-in slice

[Andrei Alexandrescu]

On 2021-11-08 20:22, rikki cattermole wrote:
> 
> On 09/11/2021 2:14 PM, tsbockman wrote:
>> What you seem to be asking for instead is a way to trick the type 
>> system into agreeing that mutating a reference count doesn't actually 
>> mutate anything, which is nonsense. If that's really necessary for 
>> some reason, it needs to be special cased into the language spec, like 
>> how `pure` explicitly permits memory allocation.
> 
> Imagine saying to someone:
> 
> Yes you have made this struct immutable.
> 
> Yes you have set this bit of memory containing that immutable struct to 
> read only.
> 
> Yes you ended up with a crashed program because that immutable struct 
> went ahead and tried to write to that read only memory.
> 
> And yes, I understand that you couldn't have known that a field that you 
> didn't write the implementation of used an escape hatch to write to 
> const data.
> 
> It doesn't make sense.

It makes perfect sense.

Yes you have made this struct immutable.

Yes you have set this bit of memory containing that immutable struct to 
read only.

Yes the immutable structure has metadata associated with it that is not 
mutable.

Yes that metadata can be in fact lying next to the data itself (for 
optimization purposes) even though it's conceptually global.

No you cannot end up with a crashed program because the mutable metadata 
and the immutable part are carefully handled so as to not interfere.

And yes, I understand that you may find that odd.