Henri Sivonen

Note: My assumption is that UTS 46 section 4.1 Validity Criteria items 1 and 6 would be checked by applying the Map & Normalize primitive proposed above and checking the...

Oh, and the data needs to support flagging disallowed-if-UseSTD3ASCIIRules=true (and `ComposingNormalizer::try_new_uts46_without_ignored_and_disallowed_unstable` needs to reflect UseSTD3ASCIIRules=false).

We need a trie with two bits per scalar value. We could pack the bits for four scalar values in one `u8` trie value by shifting the code point value...

Current notes: * The data [contemplated earlier](https://github.com/unicode-org/icu4x/issues/2850#issuecomment-1335123923) should probably go into `icu_normalizer` so that `icu_normalizer` can expose a coherent operation to an IDNA crate instead of exposing a weird normalization...

From merely looking at the data with knowledge of the relevant data structure, making everyone carry the STD3 disallowed info does not seem particularly nice, but I haven't actually measured,...

Now that I've looked at this some more, it seems to me that It's a bad idea to check the input scalar values for being STD3-disallowed and instead of makes...

For decomposition, it should be fine to make the ICU4X code operate on `u32` and to make the current `char`-argument version a convenience wrapper on top of that. For composition,...

> or take the position that if HarfBuzz passes non-scalar values that's the kind of error in using the HarfBuzz API that UB is acceptable. The HarfBuzz API for bypassing...

Sorry about missing that this was blocking on me. My preference is that we trust that scalar values that we receive from HarfBuzz are indeed scalar values and, therefore, can...

> Re-opening to seek additional feedback from @markusicu and @hsivonen * We shouldn't add sort keys at this time on performance grounds, as there is an obviously-imaginable unimplemented performance improvement...