Henri Sivonen

Ideally 1.0, but realistically probably 1.1.

I suggest creating a borrowed counterpart of `CodePointTrie` that holds `ZeroSlice`s instead of `ZeroVec`s, making `CodePointTrie` to deref into that type and moving the lookup code onto the borrowed type....

Adding the discuss-priority label to discuss whether the idea from my previous comment would be a breaking change after 1.0 and, therefore, would have to be done before 1.0.

This doesn't need to be scheduled for any particular milestone, but it also doesn't make sense to intentionally defer this. Let's say tentatively 1.1.

I'm not convinced that consistency at the cost of perf is the right way to go. I am in favor of consistency in terms of types, i.e. `std::string_view` for UTF-8-ish...

Also, would the check go on the C++ layer only or on the C/FFI layer? I.e. would JS go through a conversion from UTF-16 to guaranteed-well-format UTF-8 and still undergo...

Considering that the normalizer and the collator have been designed to be able to deal with all three of 1. guaranteed-well-formed UTF-8 2. potentially-ill-formed UTF-8 3. potentially-ill-formed UTF-16 performance-wise optimally,...

The UTF-8 part of the above makes sense. Thank you. Why do you say `&[u16]` needs to be validated? What UTF-16-taking APIs do we have that don't already deal with...

> Is this fixed by #2378? No, this is a follow-up to that one.

> Perhaps on this level of loop tightness, branching on the `ZeroVec` borrow vs. owned discriminant is significant. This appear to be the case especially when the queried-for character doesn't...