Making RCSlice and DIP74 work with const and immutable
Zach the Mystic via Digitalmars-d
digitalmars-d at puremagic.com
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