[Pitch] Safe UTF-8 Processing Over Contiguous Bytes

[florianpircher]

Is the More Collectiony algorithms section missing its end:?

@Michael_Ilseman

However, we can add select high-value algorithms if motivated by the community. We'd want to

---

Seeing the public inclusion of isKnownNFC and isKnownSingleScalarCharacters, could this be taken as motivation to also expose isKnownASCII on String as proposed here:?

@Michael_Ilseman

Future work: As for String.isASCII, we definitely will want to expose these kinds of queries in conjunction with work on performance flags, where the standard library will want to track known-ASCII-ness and other properties to enable processing fast paths. In that world, there's a isKnownASCII vs isASCII split, where that latter may require a scan of the entire String to compute.

I like this pitch for UTF8Span very much, but some low-level tasks interface with UI, logging, or other use cases that expect a regular Swift String. Exposing more low-level APIs on String directly would reduce the need to convert between these different types and improve performance for use cases where String would otherwise suffice.