On Wednesday, March 07, 2018 12:53:16 Guillaume Piolat via Digitalmars-d 
> 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

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

Reply via email to