Michel Fortin Wrote:
> 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/
>
First thing, the question of possibility is irrelevant since I could also write
the same algorithm in brainfuck or assembly (with a lot more code). It's never
a question of possibility but rather a question of ease of use for the user.
What I want is to encapsulate all the low-level implementation details in one
place so that the as a user I will not need to deal with this everywhere. one
such detail is the encoding.
auto text = w"whatever"; // should be equivalent to:
auto text = new Text("whatever", Encoding.UTF16);
now I want to write my own string function:
void func(Text a); // instead of current:
void func(T)(T a) if isTextType(T); // why the USER needs all this?
Of course, the Text type would do the correct think by default which we both
agree should be graphemes. Only if I need something advanced like in the
previous algorithm than I explicitly need to specify that I work on code points
or code units.
In a sentence: "Make the common case trivial and the complex case possible".
The common case is what we Humans think of as characters (graphemes) and the
complex case is the encoding level.
