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

[Seb]

On Tuesday, 17 July 2018 at 18:43:47 UTC, jmh530 wrote:
> 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,

Well AFAICT the idea is that with RCIAllocator (or its 
convenience function allocatorObject) is that you can convert any 
allocator to a reference-counted one, e.g.

RCIAllocator a = allocatorObject(Mallocator.instance);

> 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...

Yes, Array is a reference-counted Array, but it also has a 
reference-counted allocator.

> 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.

There's lots of stuff in rcstring related to better 
interoperability with existing strings.
e.g. you just want `"foo".rcstring == "foo"` to work.

> 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.

Yes rcstring doesn't do any auto-decoding and hence stores its 
data as an ubyte array.

> 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.

What do you mean by this?