sorting a string
ag0aep6g via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Fri Jul 14 13:36:35 PDT 2017
On 07/14/2017 09:50 PM, Anton Fediushin wrote:
> But why? This should be true for `char[]`, isn't it?
> -----
> if ((ss == SwapStrategy.unstable && (hasSwappableElements!Range ||
> hasAssignableElements!Range) || ss != SwapStrategy.unstable &&
> hasAssignableElements!Range) && isRandomAccessRange!Range &&
> hasSlicing!Range && hasLength!Range)
> -----
No, those are all false. char[] is treated as a range of code points
(dchar), not code units (char). It's decoded on-the-fly ("auto decoding").
Code unit sequences are variable in length. So to get the n-th code
point you have to decode everything before it. That's too expensive to
be considered random access.
Same for swappable/assignable elements: When the new sequence has a
different length than the old one, you have to move everything that
follows to make room or to close the gap. Too expensive to be accepted
by the templates.
As for why auto-decoding is a thing:
The idea was to treat char[] and friends as ranges of visual characters
to have a robust default where you don't accidentally mess your strings
up. Unfortunately, a code point isn't always what's commonly understood
as a character (grapheme), and the whole things falls apart. It's a
historical accident, really.
Here's a huge discussion thread about maybe getting rid of it:
http://forum.dlang.org/post/nh2o9i$hr0$1@digitalmars.com
And here's what I took away from that:
http://forum.dlang.org/post/nirpdo$167i$1@digitalmars.com
More information about the Digitalmars-d-learn
mailing list