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

[Jonathan M Davis]

On Tuesday, July 17, 2018 15:21:30 Seb via Digitalmars-d 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)
>
> Still to be done:
>
> - integration in Phobos (the current idea is to generate
> additional overloads for rcstring)
> - performance
> - use of static immutable rcstring in fully @nogc
> - extensive testing
>
> Especially the "seamless" integration in Phobos will be
> challenging.
> I made a rough listing of all symbols that one would expect to be
> usable with an rcstring type
> (https://gist.github.com/wilzbach/d74712269f889827cff6b2c7a08d07f8). It's
> more than 200. As rcstring isn't a range by default, but one excepts
> `"foo".rcstring.equal("foo")` to work, overloads for all these
> symbols would need to be added.
>
> What do you think about this approach? Do you have a better idea?

If it's not a range by default, why would you expect _anything_ which
operates on ranges to work with rcstring directly? IMHO, if it's not a
range, then range-based functions shouldn't work with it, and I don't see
how they even _can_ work with it unless you assume code units, or code
points, or graphemes as the default. If it's designed to not be a range,
then it should be up to the programmer to call the appropriate function on
it to get the appropriate range type for a particular use case, in which
case, you really shouldn't need to add much of any overloads for it.

- Jonathan M Davis