On Wednesday, March 07, 2018 12:53:16 Guillaume Piolat via Digitalmars-d wrote: > On Wednesday, 7 March 2018 at 06:00:30 UTC, Taylor Hillegeist > > wrote: > > That way the breaking change was easily fixable, and the > > mistakes of the past not forever. Is it just the cost of > > maintenance? > > auto-decoding problem was mostly that it couldn't be @nogc since > throwing, but with further releases exception throwing will get > @nogc. So it's getting fixed.
I'd actually argue that that's the lesser of the problems with auto-decoding. The big problem is that it's auto-decoding. Code points are almost always the wrong level to be operating at. The programmer needs to be in control of whether the code is operating on code units, code points, or graphemes, and because of auto-decoding, we have to constantly avoid using the range primitives for arrays on strings. Tons of range-based code has to special case for strings in order to work around auto-decoding. We're constantly fighting our own API in order to process strings sanely and efficiently. IMHO, @nogc and nothrow don't matter much in comparison. Yes, it would be nice if range-based code operating on strings were @nogc and nothrow, but most D code really doesn't care. It uses the GC anyway, and most of the time, no exceptions are thrown, because the strings are valid Unicode. Yes, the fact that the range primitives for strings throw UTFExceptions instead of using the Unicode replacement character is a problem, but that problem is small in comparison to the problems caused by the auto-decoding itself. Even if front and popFront used the variant of decode that used the replacement character, auto-decoding would still be a huge problem. - Jonathan M Davis
