On 2011-01-15 10:59:52 -0500, foobar <f...@bar.com> said:
Ok, I guess I missed the "byDchar()" method.
I envisioned the same algorithm looking like this:
// original string
string str = "...";
// create normalized decomposed string as a lazy range of dchar (NFD)
// Note: explicitly specify code points range:
auto decomposed = decompose(str.codePoints);
// filter to remove your favorite combining code point
auto filtered = filter!"a != 0xFABA"(decomposed);
// turn it back in composed form (NFC), optional
auto recomposed = compose(filtered);
// convert back to a string
// Note: a string type can be constructed from a range of code points
string result = string(recomposed);
The difference is that a string type is distinct from the intermediate
code point ranges (This happens in your design too albeit in a less
obvious way to the user). There is string specific code. Why not
encapsulate it in a string type instead of forcing the user to use
complex APIs with templates everywhere?
What I don't understand is in what way using a string type would make
the API less complex and use less templates?
More generally, in what way would your string type behave differently
than char[], wchar[], and dchar[]? I think we need to clarify what how
you expect your string type to behave before I can answer anything. I
mean, beside cosmetic changes such as having a codePoint property
instead of by!dchar or byDchar, what is your string type doing
differently?
The above algorithm is already possible with strings as they are,
provided you implement the 'decompose' and the 'compose' function
returning a range. In fact, you only changed two things in it: by!dchar
became codePoints, and array() became string(). Surely you're expecting
more benefits than that.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
