Making RCSlice and DIP74 work with const and immutable

via Digitalmars-d digitalmars-d at puremagic.com
Sun Mar 1 07:53:06 PST 2015


On Sunday, 1 March 2015 at 15:28:56 UTC, Jakob Ovrum wrote:
> 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.

Argh! I didn't think about this. Any chance we can deprecate this 
behaviour? It's also an obstacle for the implementation of 
thread-local heaps.

>
> There might be other problems, such as problems regarding ROM.

Not if the RC wrapper allocated the memory in the first place. It 
knows that it can't be in ROM.


More information about the Digitalmars-d mailing list