Andrei Alexandrescu: > one good thing that could come out of this thread > is abolition (through however slow a deprecation path) of s.length and > s[i] for narrow strings. Requiring s.rep.length instead of s.length and > s.rep[i] instead of s[i] would improve the quality of narrow strings > tremendously. Also, s.rep[i] should return ubyte/ushort, not char/wchar. > Then, people would access the decoding routines on the needed occasions, > or would consciously use the representation.
> Robert Jacques: >> Would slicing, i.e. s[i..j] still be valid? > > No, only s.rep[i .. j]. > >> If so, what would be the >> recommended way of finding i and j? > > find, findSplit etc. from std.algorithm, std.utf functions etc. We have discussed this topic some times in past, it's not an easy topic. I agree with the general desires under your ideas Andrei, I suggested something related, time ago. The idea of forbidding s.length, s[i] and s[i..j] for narrow strings seems interesting. (I suggested something different, to keep them but turn them into operations that do the right thing on narrow strings. Some people didn't appreciate the idea because it changes the computational complexity of such operations). But I suggest to step a bit back and look at the situation from a bit more distance, to avoid small patches to D that look like a pirate eyepatch :-) Narrow strings are more memory (and performance) efficient, and sometimes I want to slice them too, and do it correctly (so somestring.rep[i..j] is not enough). So I suggest to give something to perform correct slicing of narrow strings too. Bye, bearophile
