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