They were marked for removal in the docs (many of them were intended to
be removed in January), so now they've been removed from the docs and
marked for removal from the code in November.
This makes no semantic difference to the code, but it makes it so that
the attributes which are on one of the overloads don't make it into the
documentation (where they would imply that all of the overloads have
those attributes, which is not correct).
This change makes it so that decodeFront takes its range by ref and pops
off the code units that it decodes (unlike decode). It pretty much has
to do that, since it supports input ranges, and they can't do anything
else.
I also added decodeFront which operates on the first code point in the
range (unlike stride and strideBack, it requires a different name, since
the signatures of decode and decodeFront are almost identical - the only
difference being that decode takes the index by ref, and decodeFront
takes it as out).
It's easier to define aliases this way. I created two templates though
so that you can still pass both template arguments if you want to, and
it'll avoid breaking any code.
- Use fast path tests for non-complex unicode sequences that can be
inlined. These rely on the built-in array bounds check.
- Factor out complex cases into separate functions that do exception
based validity checks. The char[] and wchar[] versions use
pointers to avoid redundant array bounds checks, thus they can only
be trusted.
- Complete rewrite of decode for char[] to use less branching and
unrolled loops. This requires less registers AND less instructions.
The overlong check is done much cheaper on the code point.
- The decode functions were made templates to short circuit the very
restricted function inlining possibilities.
The pragmas have not been as effective as we might have liked, since
they only work with templates and can't tell you where in your code you
need to make changes, and they seemed to have been more annoying to
programmers than helpful, so we're going to discontinue them. We'll
leave them in for stuff that's actually been deprecated until deprecated
has been improved enough to take a message, but we'll leave "scheduled
for deprecation" messages to the documentation and changelog.
