On 3/10/2014 12:09 AM, Nick Sabalausky wrote:
On 3/10/2014 12:23 AM, Walter Bright wrote:
On 3/9/2014 9:19 PM, Nick Sabalausky wrote:
On 3/9/2014 6:31 PM, Walter Bright wrote:
On 3/9/2014 6:08 AM, "Marc Schütz" <schue...@gmx.net>" wrote:
Also, `byCodeUnit` and `byCodePoint` would probably be better names
than `raw`
and `decode`, to much the already existing `byGrapheme` in std.uni.
I'd vastly prefer 'byChar', 'byWchar', 'byDchar' for each of string,
wstring, dstring, and InputRange!char, etc.
'byCodePoint' and 'byDchar' are the same. However, 'byCodeUnit' is
completely
different from anything else:
string str;
wstring wstr;
dstring dstr;
(str|wchar|dchar).byChar // Always range of char
(str|wchar|dchar).byWchar // Always range of wchar
(str|wchar|dchar).byDchar // Always range of dchar
str.representation // Range of ubyte
wstr.representation // Range of ushort
dstr.representation // Range of uint
str.byCodeUnit // Range of char
wstr.byCodeUnit // Range of wchar
dstr.byCodeUnit // Range of dchar
I don't see much point to the latter 3.
Do you mean:
1. You don't see the point to iterating by code unit?
2. You don't see the point to 'byCodeUnit' if we have 'representation'?
3. You don't see the point to 'byCodeUnit' if we have 'byChar/byWchar/byDchar'?
4. You don't see the point to having 'byCodeUnit' work on UTF-32 dstrings?
(3)
3. 'byCodeUnit' if we have 'byChar/byWchar/byDchar': To avoid a "static if"
chain every time you want to use code units inside generic code. Also, so in
non-generic code you can change your data type without updating instances of
'by*char'.
Just not sure I see a use for that.
