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