Element type of string ranges

From D Wiki
Jump to: navigation, search

This article attempts to summarize the arguments in the thread Major performance problem with std.array.front().

Comparison

One of the proposals in the thread is to switch the iteration type of string ranges from dchar to the string's character type.

Argument Current behavior
(code point iteration)
Code unit iteration Code unit iteration + forbid implicit char <=> dchar conversions Notes
Status quo Green check.png The current situation, with its (dubious) advantages and known disadvantages Red x.png Will cause breakage Red x.png Will cause more breakage
Red x.png Will cause silent breakage Green check.png No silent breakage
Searching for a particular dchar in a string. Green check.png s.canFind('é') Red x.png Will result in a pragma warning in some places, will fail silently in others (when specified via predicate). Red x.png Will emit a warning or fail to compile This should not be recommended practice (not all languages have notions of characters, and not all characters (glyphs/graphemes) can be represented in one dchar).
Searching for a particular dchar in a non-normalized string. Red x.png Above fails for combining marks, as that requires normalization.
Case conversion, insensitive comparison in ranges for certain languages Green check.png s.count!((a, b) => std.uni.toLower(a) == std.uni.toLower(b))("é") Red x.png Fails silently. Red x.png Will emit a warning or fail to compile This should not be recommended practice (correct case conversion and comparison for all languages is more complicated, and depends on locale - e.g. Turkish I / ı and İ / i).
Case conversion, insensitive comparison in ranges for other languages Red x.png Fails.
Correctness Red x.png Only works for certain languages and alphabets Red x.png Only works for ASCII Red x.png Only works for ASCII; enforces correct character type conversions
Performance Red x.png Implicit decoding everywhere, unless each algorithm is specialized not to Green check.png As fast as ubyte[]
Implementation difficulty Red x.png Requires quite a bit of scaffolding:
ElementEncodingType - 80 instances
isSomeString - 138 instances
isExactSomeString - 23 instances
isSomeChar - 129 instances
Green check.png Strings are treated as any other arrays
Consistency Red x.png Inconsistencies between array and range types
Red x.png Range algorithms return values different from array algorithms
Green check.png String ranges work like ranges of any other arrays