Major performance problem with std.array.front()

[Walter Bright]

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" <schuetzm at 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.