[Issue 4483] foreach over string or wstring, where element type not specified, does not support unicode

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sun Jan 26 01:17:41 PST 2014


https://d.puremagic.com/issues/show_bug.cgi?id=4483


Walter Bright <bugzilla at digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|Other                       |All


--- Comment #11 from Walter Bright <bugzilla at digitalmars.com> 2014-01-26 01:17:28 PST ---
> You fail to recognize that it's broken from the begging.

I understand and recognize your arguments, I just do not agree with the
conclusion.

1. Silently breaking code with such a change is a seriously bad idea at this
point.

2. I do not agree with the hypothesis that the slowdown is trivial. I just got
done doing a project for a client, where high speed was essential. I got bit by
front() doing a decode. The speed hit was not acceptable, and I had to insert
lots of ugly casts to ubyte arrays. The code almost never needed a decode
character, but simply doing a copy() did a decode and then an encode. Arghh!

Actually needing a dchar is rather rare. The bulk of algorithms with strings
work better and faster using octets (like good ole' copy()). I've suspected for
a while now that std.algorithm is slower than necessary because the pointless
decoding going on, and I know that std.regex suffered serious slowdowns because
of it.

To me this is much like the recurring argument that D should hide the reality
of twos-complement arithmetic with various checks for overflows and carries. D
strings are octets, not dchars, and one simply needs to be aware of that when
programming with them.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list