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

[Seb]

On Wednesday, 18 July 2018 at 03:40:08 UTC, Jon Degenhardt 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:
>>
>> https://github.com/dlang/phobos/pull/6631 (still WIP though)
>>
>> The current approach in short:
>>
>> - uses the new @nogc, @safe and nothrow Array from the 
>> collections library (check Eduardo's DConf18 talk)
>> - uses reference counting
>> - _no_ range by default (it needs an explicit 
>> `.by!{d,w,}char`) (as in no auto-decoding by default)
>>
>> [snip]
>>
>> What do you think about this approach? Do you have a better 
>> idea?
>
> I don't know the goals/role rcstring is expected to play, 
> especially wrt existing string/character facilities. Perhaps 
> you could describe more?

Sorry for the brevity yesterday.
One of long-term pain point of D is that usage of string can't be 
@nogc.
rcstring is intended to be a drop-in @nogc replacement for 
everywhere where string is currently used (that's the idea, at 
least).

> Strings are central to many applications, so I'm wondering 
> about things like whether rcstring is intended as a replacement 
> for string that would be used by most new programs,

Yes, that's the long-term goal. An opt-in @nogc string class.
There's no plan to do sth. disruptive like replacing the `alias 
string = immutable(char)[];` declaration in druntime. However, we 
might move rcstring to druntime at some point, s.t. e.g. 
Exceptions or asserts can use @nogc strings.

> and whether applications would use arrays and ranges of char 
> together with rcstring, or rcstring would be used for 
> everything.

That point is still open for discussion, but at the moment 
rcstring isn't a range and the user has to declare what kind of 
range he/she wants with e.g. `.by!char`
However, one current idea is that for some use cases (e.g. 
comparison) it might not matter and an application could add 
overloads for rcstrings.
The current idea is to do the same this for Phobos - though I 
have to say that I'm not really looking forward to adding 200 
overloads to Phobos :/

> Perhaps its too early for these questions, and the current goal 
> is simpler. For example, adding a meaningful collection class 
> that is @nogc, @safe and ref-counted that be used as a proving 
> ground for the newer memory management facilities being 
> developed.

That's the long-term goal of the collections project.
However, with rcstring being the first big use case for it, the 
idea was to push rcstring forward and by that discover all 
remaining issues with the Array class.
Also the interface of rcstring is rather contained (and doesn't 
expose the underlying storage to the user), which allows us to 
iterate over/improve upon the Array design.

> Such simpler goals would be quite reasonable. What's got me 
> wondering about the larger questions are the comments about 
> ranges and autodecoding. If rcstring is intended as a vehicle 
> for general @nogc handling of character data and/or for 
> reducing the impact of autodecoding, then it makes sense to 
> consider from those perspectives.

Hehe, it's intended to solve both problems (auto-decoding by 
default and @nogc) at the same time.
However, it looks like to me like there isn't a good solution to 
the auto-decoding problem that is convenient to use for the user 
and doesn't sacrifice on performance.