Making RCSlice and DIP74 work with const and immutable

Zach the Mystic via Digitalmars-d digitalmars-d at
Sun Mar 1 08:45:03 PST 2015

On Sunday, 1 March 2015 at 01:40:40 UTC, Andrei Alexandrescu 
> 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)?

I need to get educated on this issue. First suggestion: Just 
break the type system by encouraging the idiom of using casts in 
opAddRef and opRelease. It's too easy, but I don't know why.

More information about the Digitalmars-d mailing list