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.