Element type of string ranges
Revision as of 03:25, 9 March 2014 by Vladimir Panteleev (talk | contribs)
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 | Old | New |
---|---|---|
Searching for a particular dchar in a string. | s.canFind('é') | Will result in a pragma warning in some places, will fail silently in others (when specified via predicate).
Note: 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. | Above fails for combining marks, as that requires normalization. | |
Case conversion, insensitive comparison in ranges for certain languages | s.count!((a, b) => std.uni.toLower(a) == std.uni.toLower(b))("é") | Fails silently.
Note: 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 | Fails. | |
Correctness | Only works for certain languages and alphabets | Only works for ASCII |
Performance | Implicit decoding everywhere, unless each algorithm is specialized not to | As fast as ubyte[] |
Implementation difficulty | phobos/std $ grep ElementEncodingType *.d | wc -l 80 |
Strings are treated as any other arrays |
Consistency | Inconsistencies between array and range types Range algorithms return values different from array algorithms |
String ranges work like ranges of any other arrays |