https://d.puremagic.com/issues/show_bug.cgi?id=4483
Walter Bright <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Platform|Other |All --- Comment #11 from Walter Bright <[email protected]> 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: -------
