Making RCSlice and DIP74 work with const and immutable
Jakob Ovrum via Digitalmars-d
digitalmars-d at puremagic.com
Sun Mar 1 07:28:54 PST 2015
On Sunday, 1 March 2015 at 01:40:40 UTC, Andrei Alexandrescu
wrote:
> 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
I don't think const or immutable intrusive-reference-counted
classes is a feasible idea.
I understand the motivation: we want to dynamically allocate a
class instance, initialize it and never mutate it again, and pass
it around freely; *without* using tracing GC. Having it typed as
immutable helps code readability and whatnot.
However, AFAICS, it comes with a serious problem. Immutable
objects are freely passable between threads, so surely an
immutable RC object would need atomic counting just like a shared
RC object, but unlike shared, immutable does not necessarily
express the intent of sharing between threads; the immutable RC
object could easily be counting atomically for nothing.
There might be other problems, such as problems regarding ROM.
This is not a problem with reference-counting as a whole but with
intrusive reference-counting. With RefCounted,
immutable(RefCounted!T) makes no sense, but RefCounted!(immutable
T) does. It's also neatly composable;
shared(RefCounted!(immutable T)) makes sense too.
I wish we had external, composable reference-counting for class
instances. I know why that's problematic, so sorry for posting
without any suggestion on how to proceed...
More information about the Digitalmars-d
mailing list