Re: Our Sister

Am Wed, 1 Jun 2016 01:06:36 +1000 schrieb Manu via Digitalmars-d : > D loves templates, but templates aren't a given. Closed-source > projects often can't have templates in the public API (ie, source > should not be available), and this is my world. Same effect for

Re: Our Sister

On 31 May 2016 at 01:00, Marco Leise via Digitalmars-d wrote: > Am Sat, 28 May 2016 14:15:45 +1000 > schrieb Manu via Digitalmars-d : > >> On 28 May 2016 at 10:16, Adam D. Ruppe via Digitalmars-d >> wrote: >>

Re: Our Sister

On Friday, 27 May 2016 at 21:25:50 UTC, Andrei Alexandrescu wrote: On 05/27/2016 05:02 PM, Era Scarecrow wrote: With the current state of things, I'll just take your word on it. Reasoning is simple - yes we could safely convert to const(char)[] but that means effectively all refcounting is

Re: Our Sister

Am Sat, 28 May 2016 14:15:45 +1000 schrieb Manu via Digitalmars-d : > On 28 May 2016 at 10:16, Adam D. Ruppe via Digitalmars-d > wrote: > > On Friday, 27 May 2016 at 21:51:59 UTC, Seb wrote: > >> > >> not if [] would be ref-counted too

Re: Our Sister

On 05/27/2016 01:17 AM, Seb wrote: > Oh yes that's what I meant. Sorry for being so confusing. > __Right__ is way more important than breakages. For that we have `dfix`. Don't get overly excited. dfix will never be capable of automatic fixup with such deep levels of semantic analysis required,

Re: Our Sister

On Saturday, 28 May 2016 at 04:15:45 UTC, Manu wrote: This is only true for the owner. If we had 'scope', or something like it (ie, borrowing in rust lingo), then the fat slice wouldn't need to be passed around Right, I agree - if we keep the slice just the way it is now, it all still works

Re: Our Sister

On Saturday, 28 May 2016 at 04:28:16 UTC, Manu wrote: On 27 May 2016 at 23:32, Andrei Alexandrescu via Digitalmars-d wrote: On 5/27/16 7:07 AM, Marc Schütz wrote: It should _safely_ convert to `const(char)[]`. That is not possible, sorry. -- Andrei It should

Re: Our Sister

On Friday, 27 May 2016 at 13:32:30 UTC, Andrei Alexandrescu wrote: On 5/27/16 7:07 AM, Marc Schütz wrote: On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote: RFC: what primitives should RCStr have? It should _safely_ convert to `const(char)[]`. That is not possible, sorry.

Re: Our Sister

On Saturday, 28 May 2016 at 09:43:41 UTC, ZombineDev 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: RCStr may be an ea

Re: Our Sister

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: RCStr may be an easier first step, but I think generic dynamic arrays are more i

Re: Our Sister

On Saturday, 28 May 2016 at 04:31:22 UTC, Manu wrote: On 27 May 2016 at 02:11, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote: I've been working on RCStr (endearingly pronounced "Our Sister"), Ah, I totally skipped over this thread... Wow... thi

Re: Our Sister

On 27 May 2016 at 02:11, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > I've been working on RCStr (endearingly pronounced "Our Sister"), Ah, I totally skipped over this thread... Wow... this really doesn't work in any accent I'm close to, but

Re: Our Sister

On 27 May 2016 at 23:32, Andrei Alexandrescu via Digitalmars-d wrote: > On 5/27/16 7:07 AM, Marc Schütz wrote: >> >> On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote: >>> >>> RFC: what primitives should RCStr have? >> >> >> It should _safely_

Re: Our Sister

On 28 May 2016 at 10:16, Adam D. Ruppe via Digitalmars-d wrote: > On Friday, 27 May 2016 at 21:51:59 UTC, Seb wrote: >> >> not if [] would be ref-counted too ;-) > > > That would be kinda horrible. Right now, slicing is virtually free and > compatible with all kinds

Re: Our Sister

On 05/27/2016 06:09 PM, tsbockman wrote: On Friday, 27 May 2016 at 21:25:50 UTC, Andrei Alexandrescu wrote: On 05/27/2016 05:02 PM, Era Scarecrow wrote: With the current state of things, I'll just take your word on it. Reasoning is simple - yes we could safely convert to const(char)[] but

Re: Our Sister

On Friday, 27 May 2016 at 22:09:48 UTC, tsbockman wrote: But conversions to scope const(char)[] could be made safe, right? (If scope were ever fully implemented, that is.) Indeed, and I really think we should spend more effort on making this work. Not as much as Rust spends on it, but a lil

Re: Our Sister

On Friday, 27 May 2016 at 21:51:59 UTC, Seb wrote: not if [] would be ref-counted too ;-) That would be kinda horrible. Right now, slicing is virtually free and compatible with all kinds of backing schemes. If it became refcounted, it'd: 1) have to keep a pointer to the refcount structure

Re: Our Sister

On Friday, 27 May 2016 at 21:25:50 UTC, Andrei Alexandrescu wrote: On 05/27/2016 05:02 PM, Era Scarecrow wrote: With the current state of things, I'll just take your word on it. Reasoning is simple - yes we could safely convert to const(char)[] but that means effectively all refcounting is

Re: Our Sister

On Friday, 27 May 2016 at 21:25:50 UTC, Andrei Alexandrescu wrote: On 05/27/2016 05:02 PM, Era Scarecrow wrote: With the current state of things, I'll just take your word on it. Reasoning is simple - yes we could safely convert to const(char)[] but that means effectively all refcounting is

Re: Our Sister

On 05/27/2016 05:02 PM, Era Scarecrow wrote: With the current state of things, I'll just take your word on it. Reasoning is simple - yes we could safely convert to const(char)[] but that means effectively all refcounting is lost for that string. So we can convert but in an explicit manner,

Re: Our Sister

On Friday, 27 May 2016 at 13:32:30 UTC, Andrei Alexandrescu wrote: On 5/27/16 7:07 AM, Marc Schütz wrote: On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote: RFC: what primitives should RCStr have? It should _safely_ convert to `const(char)[]`. That is not possible, sorry.

Re: Our Sister

On 5/27/16 7:07 AM, Marc Schütz wrote: On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote: RFC: what primitives should RCStr have? It should _safely_ convert to `const(char)[]`. That is not possible, sorry. -- Andrei

Re: Our Sister

On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote: RFC: what primitives should RCStr have? It should _safely_ convert to `const(char)[]`.

Re: Our Sister

On Thursday, 26 May 2016 at 17:32:33 UTC, Jack Stouffer wrote: *bikeshedding*: How about RCString, because the convention for D names is to be explicit most of the time. +1

Re: Our Sister

On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote: * Fast: use the small string optimization and various other layout and algorithms to make it a good choice for high performance strings For inspiration see: - Vladimir recommends `tempCString` - Nikolay has

Re: Our Sister

On Thu, May 26, 2016 at 04:24:10PM -0400, Andrei Alexandrescu via Digitalmars-d 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.

Re: Our Sister

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

Re: Our Sister

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

Re: Our Sister

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

Re: Our Sister

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,

Re: Our Sister

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

Re: Our Sister [i.e. RCStr/RCString]

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

Re: Our Sister

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

Re: Our Sister

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

Re: Our Sister

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

Re: Our Sister

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 o

Re: Our Sister

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

Re: Our Sister

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.

Re: Our Sister

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,

Re: Our Sister

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,

Re: Our Sister

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 o

Our Sister

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. * S