Major performance problem with std.array.front()

Walter Bright newshound2 at digitalmars.com
Thu Mar 6 19:57:49 PST 2014


On 3/6/2014 7:31 PM, H. S. Teoh wrote:
> Whoa. You're not serious about changing this now, are you? Because even
> though I would support such a change, you have to realize the magnitude
> of code breakage that will happen. A lot of code that iterates over
> narrow strings will break, and worse yet, they will break *silently*.
> Calling count() on a narrow string will not return the expected value,
> for example. And existing code that iterates over narrow strings
> expecting dchars to come out of it will suddenly silently convert to
> char, and may pass by unnoticed until somebody runs the program with a
> multibyte character in the input.

I understand this all too well. (Note that we currently have a different silent 
problem: unnoticed large performance problems.)


> This is very high risk change IMO.
>
> You're welcome to create a (temporary) Phobos fork that reverts narrow
> string auto-decoding, of course, and people can try it out to see how
> much actual breakage is happening. If you really want to push for this,
> that might be the safest way to test the waters before committing to
> such a major change. Silent breakage is not easy to test for,
> unfortunately. :(

I posted a plan in another message in this thread. It'll be a long process, but 
I think it's doable.



More information about the Digitalmars-d mailing list