Major performance problem with std.array.front()

[Marc Schütz" <schuetzm at gmx.net>]

On Monday, 10 March 2014 at 13:18:50 UTC, Dicebot wrote:
> On Sunday, 9 March 2014 at 17:27:20 UTC, Andrei Alexandrescu 
> wrote:
>> On 3/9/14, 6:47 AM, "Marc Schütz" <schuetzm at gmx.net>" wrote:
>>> On Friday, 7 March 2014 at 15:03:24 UTC, Dicebot wrote:
>>>> 2) It is regression back to C++ days of 
>>>> no-one-cares-about-Unicode
>>>> pain. Thinking about strings as character arrays is so 
>>>> natural and
>>>> convenient that if language/Phobos won't punish you for 
>>>> that, it will
>>>> be extremely widespread.
>>>
>>> Not with Nick Sabalausky's suggestion to remove the 
>>> implementation of
>>> front from char arrays. This way, everyone will be forced to 
>>> decide
>>> whether they want code units or code points or something else.
>>
>> Such as giving up on that crappy language that keeps on 
>> breaking their code.
>>
>> Andrei
>
>
> That was more about "if you are that crazy to even consider 
> such breakage, this is closer my personal perfection" than 
> actual proposal ;)

BTW, I don't believe it would be that bad, because there's a 
straight-forward path of deprecation:

First, std.range.front for narrow strings (and dchar, for 
consistency) can be marked as deprecated. The deprecation message 
can say: "Please specify .byCodePoint()/.byCodeUnit()", guiding 
the users towards a better style (assuming one agrees that 
explicit is indeed better than implicit in this case).

After some time, the functionality can be moved into a 
compatibility module, with the deprecated functions still there, 
but now additionally telling the user about the quick fix of 
importing that module.

The deprecation period can be very long, and even if the 
functions should never be removed, at least everyone writing new 
code would do so in the new style.