VLERange: a range in between BidirectionalRange and RandomAccessRange

[Michel Fortin]

On 2011-01-15 10:59:52 -0500, foobar <foo at 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.fortin at michelf.com
http://michelf.com/