[Dlang-study] [rcstring] Defining rcstring

[Jonathan M Davis]

On Wednesday, February 03, 2016 15:20:21 Marc Schütz wrote:
> I assume you also don't want to allow access to the underlying
> storage (most likely `char[]`?). I don't see this as a good thing
> at all. Without the ability of getting at least a `const(char)[]`
> out of it, RCString would be next to useless in practice.

Would it? Most string code is really supposed to be range-based at this
point anyway, in which case, the fact that it doesn't convert to some
variant of char[] is pretty much a non-issue. The only real problem is the
code that takes something like string or const(char)[] explicitly, and maybe
some of that code shouldn't be doing that.

In any case, with opIndex and length gone, what we get with RCString is
really more a container of code units that gives us various types of ranges
over it rather than a string, which means that complaining that you can't
get a char[] out of it is a bit like complaining that you can't get a char[]
out of an Array!char or a DList!char. Sure, there are cases where it won't
work, but in most cases, it will, because most stuff is range-based.

> > * Immutable does not play well with reference counting. I'm of
> > a mind to reject immutable rcstring for now and figure out
> > later how to go about it. Then const rcstring is okay because
> > we always consider const a view on mutable strings (even though
> > they're gone). We'll cast const away when manipulating the
> > refcount.

Does immutable even make sense for a ref-counted object? You can't share a
ref-counted object across threads without shared anyway, because the
ref-count needs to be protected to be thread-safe. So, why not just use
const? It's just as good as immutable if you have no mutable references, and
you can't share across threads implicitly anyway. I'm sure that it merits a
larger discussion, but at the moment, I'm inclined to believe that immutable
simply doesn't make sense for ref-counted objects.

- Jonathan M Davis