On Tuesday, May 31, 2016 13:01:11 Andrei Alexandrescu via Digitalmars-d wrote: > On 05/31/2016 12:45 PM, Jonathan M Davis via Digitalmars-d wrote: > > On Tuesday, May 31, 2016 11:07:09 Andrei Alexandrescu via Digitalmars-d wrote: > >> On 5/31/16 3:56 AM, Walter Bright wrote: > >>> If there is an abstraction for strings that is efficient, consistent, > >>> useful, and hides the fact that it is UTF, I am not aware of it. > >> > >> It's been mentioned several times: a string type that does not offer > >> range primitives; instead it offers explicit primitives (such as > >> byCodeUnit, byCodePoint, byGrapheme etc) that yield appropriate ranges. > > > > Not exactly. Such a string type does not hide the fact that it's UTF. > > Rather, it forces you to deal with the fact that its UTF. > > How is that different from what I said? -- Andrei
My point was that Walter was stating that you can't have a type that hides the fact that it's dealing with Unicode while still being efficient, whereas you mentioned a proposal for a type that does not hide the fact that it's dealing with Unicode. So, you weren't really responding with a type that rebutted Walter's statement. Rather, you responded with a type that attempts to make its Unicode nature more explicit than immutable(char)[]. - Jonathan M Davis