Making RCSlice and DIP74 work with const and immutable

[Manu via Digitalmars-d]

On 1 March 2015 at 11:40, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> 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)?
>
>
> Andrei

Perhaps an operator that may be implemented to return a mutable
metadata pointer for objects? From an algebraic point of view, it
should be defined that mutating metadata will have no effect on the
actual object.

Interestingly, I wonder if such an approach may also be used to
satisfy a common problem that people have with const objects, where
it's not possible to implement caching systems for repeated work
optimisation?
The result cache is another thing that may be stored in the object's
metadata...?