std.experimental.collections.rcstring and its integration in Phobos

jmh530 john.michael.hall at gmail.com
Tue Jul 17 18:43:47 UTC 2018


On Tuesday, 17 July 2018 at 15:21:30 UTC, Seb wrote:
> So we managed to revive the rcstring project and it's already a 
> PR for Phobos:
>
> [snip]
>

I'm glad this is getting worked on. It feels like something that 
D has been working towards for a while.

Unfortunately, I haven't (yet) watched the collections video at 
Dconf and don't see a presentation on the website. Because of 
that, I don't really understand some of the design decisions.

For instance, I also don't really understand how RCIAllocator is 
different from the old IAllocator (the documentation could use 
some work, IMO). It looks like RCIAllocator is part of what 
drives the reference counting semantics, but it also looks like 
Array has some support for reference counting, like addRef, that 
invoke RCIAllocator somehow. But Array also has some support for 
gc_allocator as the default, so my cursory examination suggests 
that Array is not really intended to be an RCArray...

So at that point I started wondering why not just have String as 
an alias of Array, akin to how D does it for dynamic arrays to 
strings currently. If there is stuff in rcstring now that isn't 
in Array, then that could be included in Array as a compile-time 
specialization for the relevant types (at the cost of bloating 
Array). And then leave it up to the user how to allocate.

I think part of the above design decision connects in with why 
rcstring stores the data as ubytes, even for wchar and dchar. 
Recent comments suggest that it is related to auto-decoding. My 
sense is that an rcstring that does not have auto-decoding, even 
if it requires more work to get working with phobos is a better 
solution over the long-run.


More information about the Digitalmars-d mailing list