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