On Thu, Sep 25, 2014 at 09:19:29PM +0000, via Digitalmars-d wrote: > On Thursday, 25 September 2014 at 21:03:53 UTC, Walter Bright wrote: [...] > >I have yet to completely convince Andrei that autodecoding is a bad > >idea :-(
It certainly represents a runtime overhead, which may be non-negligible depending on your particular use case, and despite oft stated benefits of being Unicode-aware by default (well, not 100%), I think the cost of maintaining special-casing for narrow strings is starting to show up in the uglification of Phobos range-based code. Ranges were supposed to help with writing cleaner, more generic code, but I've been observing a trend of special-casing in order to reduce the autodecoding overhead in string handling, which somewhat reduces the cleanness of otherwise fully-generic code. This complexity has led to string-related bugs, and definitely has a cost on the readability (and, consequently, maintainability) of Phobos code. Special cases hurt generic code. It's not just about performance. > I think it should just refuse to work on char[], wchar[] and dchar[]. > Instead, byCodeUnit, byCodePoint (which already exist) would be > required. This way, users would need to make a conscious decision, > and there would be no surprises and no negative performance impact. Not a bad idea. If we do it right, we could (mostly) avoid user outrage. E.g., start with a "soft deprecation" (a compile-time message, but not an actual warning, to the effect that byCodeUnit / byCodePoint should be used with strings from now on), then a warning, then an actual deprecation, then remove autodecoding code from Phobos algorithms (leaving only byCodePoint for those who still want autodecoding). T -- Two wrongs don't make a right; but three rights do make a left...
