Making RCSlice and DIP74 work with const and immutable

[Michel Fortin via Digitalmars-d]

On 2015-03-01 01:40:42 +0000, Andrei Alexandrescu said:

> Tracing garbage collection can afford the luxury of e.g. mutating data 
> that was immutable during its lifetime.
> 
> Reference counting needs to make minute mutations to data while 
> references to that data are created. In fact, it's not mutation of the 
> "useful" data, the payload of a data structure; it's mutation of 
> metadata, additional information about the data (i.e. a reference count 
> integral).
> 
> The RCOs described in DIP74 and also RCSlice discussed in this forum 
> need to work properly with const and immutable. Therefore, they need a 
> way to reliably define and access metadata for a data structure.
> 
> One possible solution is to add a "@mutable" or "@metadata" attribute 
> similar to C++'s keyword "mutable". Walter and I both dislike that 
> solution because it's hamfisted and leaves too much opportunity for 
> abuse - people can essentially create unbounded amounts of mutable 
> payload for an object claimed to be immutable. That makes it impossible 
> (or unsafe) to optimize code based on algebraic assumptions.
> 
> We have a few candidates for solutions, but wanted to open with a good 
> discussion first. So, how do you envision a way to define and access 
> mutable metadata for objects (including immutable ones)?

Store the metadata in a global hash table.

There's a problem with reference counting immutable objects: they are 
implicitly shared. Any metadata attached to them thus needs to be 
shared. Accessing the metadata through a global shared hash table isn't 
going to be that much of a performance hit compared to whatever 
mechanism is used to synchronize access to that data.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/