I've been working on RCStr (endearingly pronounced "Our Sister"), D's up-and-coming reference counted string type. The goals are:

* Reference counted, shouldn't leak if all instances destroyed; even if not, use the GC as a last-resort reclamation mechanism.

* Entirely @safe.

* Support UTF 100% by means of RCStr!char, RCStr!wchar etc. but also raw manipulation and custom encodings via RCStr!ubyte, RCStr!ushort etc.

* Support several views of the same string, e.g. given s of type RCStr!char, it can be iterated byte-wise, code point-wise, code unit-wise etc. by using s.by!ubyte, s.by!char, s.by!dchar etc.

* Support const and immutable qualifiers for the character type.

* Work well with const and immutable when they qualify the entire RCStr type.

* Fast: use the small string optimization and various other layout and algorithms to make it a good choice for high performance strings

RFC: what primitives should RCStr have?


Thanks,

Andrei

On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote:
> I've been working on RCStr (endearingly pronounced "Our Sister")

You really should actually mention RCStr in the subject line so people overwhelmed with the staggering amount of off topic chatter on this forum don't disregard this thread too.

On Thursday, 26 May 2016 at 16:20:37 UTC, Adam D. Ruppe wrote:
> On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote:
>> I've been working on RCStr (endearingly pronounced "Our Sister")
>
> You really should actually mention RCStr in the subject line so people overwhelmed with the staggering amount of off topic chatter on this forum don't disregard this thread too.

To be fair using a forum called 'General' for technical discussion is asking for trouble. We will be able to tell when D actually starts to become popular because this part of the forum will cease to function as it's inundated with newbies who expect it to mean general questions or something similar.

On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote:
> * Support several views of the same string, e.g. given s of type RCStr!char, it can be iterated byte-wise, code point-wise, code unit-wise etc. by using s.by!ubyte, s.by!char, s.by!dchar etc.

Will s.by!Grapheme be supported too?

On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote:
> * Support const and immutable qualifiers for the character type.

How is that going BTW. Last I heard you were having problems with inout/const.

> * Support several views of the same string, e.g. given s of type RCStr!char, it can be iterated byte-wise, code point-wise, code unit-wise etc. by using s.by!ubyte, s.by!char, s.by!dchar etc.
>
> [snip]
>
> RFC: what primitives should RCStr have?

Well, because we already have the standard library functions representation, byUTF, byCodePoint, byCodeUnit, and byGrapheme, I think RCStr should provide these names as methods which all return ranges. If possible, these would all work regardless of character or integer type of the data. So in effect, RCStr would have completely encapsulated data. Let's not make the same mistake that we made with string et al. by providing a default.

If at all possible, it would be great if it was also an output range.

> RCStr

*bikeshedding*: How about RCString, because the convention for D names is to be explicit most of the time.

On 05/26/2016 12:58 PM, Gary Willoughby wrote:
> On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote:
>> * Support several views of the same string, e.g. given s of type
>> RCStr!char, it can be iterated byte-wise, code point-wise, code
>> unit-wise etc. by using s.by!ubyte, s.by!char, s.by!dchar etc.
>
> Will s.by!Grapheme be supported too?

Yes. -- Andrei

On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote:
> I've been working on RCStr (endearingly pronounced "Our Sister"), D's up-and-coming reference counted string type. The goals are:
> ...

I don't know how practical this would be, but if at all feasible, I think one of the goals should be to have a common interface/primitives with regular strings so we can write generic functions which accept both native strings and RCStr.

Otherwise, I second Jack's points.

> * Reference counted, shouldn't leak if all instances destroyed; even if not, use the GC as a last-resort reclamation mechanism.

Could you (or somebody) elaborate a little on how this could work from a technical standpoint? The only way I see this working is if the GC always scans for RCStr-allocated memory, in which case, why even bother with RC?

On Thursday, 26 May 2016 at 17:32:33 UTC, Jack Stouffer wrote:
> Well, because we already have the standard library functions representation, byUTF


That would be templated so like byUTF!char and byUTF!wchar right?

Then byCodePoint can just be another name for byUTF!dchar. I kinda like that.

Ideally, the string type would also use lazy imports for any conversion table. So if you never call byGrapheme, it never imports the std.uni tables. (Heck, std.uni could be the one to provide that type, of course.)


Would an RCStr pass isSomeString? I kinda think it shouldn't. Actually, isSomeString probably shouldn't often be used - instead checking for string-like range capabilities is likely better for algorithms. Then doing some_algorithm(my_rcstr) fails - you must do some_algorithm(my_rcstr.some_range)

On Thursday, 26 May 2016 at 17:50:36 UTC, Adam D. Ruppe wrote:
> That would be templated so like byUTF!char and byUTF!wchar right?
>
> Then byCodePoint can just be another name for byUTF!dchar. I kinda like that.
>
> Ideally, the string type would also use lazy imports for any conversion table. So if you never call byGrapheme, it never imports the std.uni tables. (Heck, std.uni could be the one to provide that type, of course.)

This has the added benefit that it would automatically work with a lot of generic code that uses those functions.

> Would an RCStr pass isSomeString? I kinda think it shouldn't.

I agree, it shouldn't. isSomeString should only test for one of the language provided string types.

On Thursday, 26 May 2016 at 16:20:37 UTC, Adam D. Ruppe wrote:
> On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote:
>> I've been working on RCStr (endearingly pronounced "Our Sister")
>
> You really should actually mention RCStr in the subject line so people overwhelmed with the staggering amount of off topic chatter on this forum don't disregard this thread too.

Where do you see all this "chatter?"  Looking at the topics for the last 10 days, I only see one not about D generally, and it's labeled OT.