On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote:
> RFC: what primitives should RCStr have?

Having a "null" state which is distinguishable from an empty string.

On Thursday, 26 May 2016 at 17:45:15 UTC, Xinok wrote:
> 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.

Great news!
I think one can't stress this enough: If you want RCStr to be adapted it has to be a drop-in replacement for string.

Maybe we can bundle the transition from auto-decoding with the adaption to a RCString. There was the proposal of having String without auto-decoding for this migration.

On Thursday, 26 May 2016 at 18:44:42 UTC, Seb wrote:
>
> Great news!
> I think one can't stress this enough: If you want RCStr to be adapted it has to be a drop-in replacement for string.
>
> Maybe we can bundle the transition from auto-decoding with the adaption to a RCString. There was the proposal of having String without auto-decoding for this migration.

I like these ideas (and RCString over RCStr).

On Thursday, May 26, 2016 17:50:36 Adam D. Ruppe via Digitalmars-d wrote:
> 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)

RCStr definitely should _not_ pass isSomeString. Those traits specifically work only for the built-in types and not for stuff that acts like them. It's a disaster waiting to happen otherwise. We need to distinguish between testing for something that is a string and something that acts like one.

- Jonathan M Davis

On Thursday, May 26, 2016 16:20:37 Adam D. Ruppe via Digitalmars-d 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.

Yeah. I was about to ignore this thread as being clearly OT until I saw that it was started by Andrei.

- Jonathan M Davis

On 05/26/2016 02:44 PM, Seb wrote:
> If you want RCStr to be adapted it has to be a drop-in replacement for
> string.

With all the criticism leveled against string, I thought more of the opposite. This is an opportunity to get it right. -- 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:
>
> * 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


Interesting! I few noob questions first:

* Would it support implicit sharing (copy-on-write)? What about sub-strings?

* Will concatenations be fast?

* Would this have value for compile time string operations, mixin's, etc.?


> RFC: what primitives should RCStr have?

String may have a few that are worth supporting: http://doc.qt.io/qt-5/qstring.html

Bastiaan.

On 05/26/2016 04:32 PM, Bastiaan Veelo wrote:
> * Would it support implicit sharing (copy-on-write)? What about
> sub-strings?

Yes, COW. Substrings will be managed COW-ish as well (no copy upon substring extraction).

> * Will concatenations be fast?

No, it will copy (i.e. no multiple segments management). It will be of course optimized as much as we can.

> * Would this have value for compile time string operations, mixin's, etc.?

Not planned.

>> RFC: what primitives should RCStr have?
>
> String may have a few that are worth supporting:
> http://doc.qt.io/qt-5/qstring.html

Good list. Thanks!


Andrei

On Thursday, 26 May 2016 at 20:24:10 UTC, Andrei Alexandrescu wrote:
> On 05/26/2016 02:44 PM, Seb wrote:
>> If you want RCStr to be adapted it has to be a drop-in replacement for
>> string.
>
> With all the criticism leveled against string, I thought more of the opposite. This is an opportunity to get it right. -- Andrei

Hmm, I think it would be better to be right than necessarily a drop-in. I think the idea is so that you could change
alias string = immutable(char)[];
to something using RCString and there would be minimal breakages.

On Thursday, 26 May 2016 at 21:42:31 UTC, jmh530 wrote:
> On Thursday, 26 May 2016 at 20:24:10 UTC, Andrei Alexandrescu wrote:
>> On 05/26/2016 02:44 PM, Seb wrote:
>>> If you want RCStr to be adapted it has to be a drop-in replacement for
>>> string.
>>
>> With all the criticism leveled against string, I thought more of the opposite. This is an opportunity to get it right. -- Andrei
>
> Hmm, I think it would be better to be right than necessarily a drop-in. I think the idea is so that you could change
> alias string = immutable(char)[];
> to something using RCString and there would be minimal breakages.

Oh yes that's what I meant. Sorry for being so confusing.
__Right__ is way more important than breakages. For that we have `dfix`.