Re: [whatwg/encoding] Consider adding TextEncoder.containsLoneSurrogates() static (#174)

> @hsivonen The input event issue is a problem, but I think one problem shouldn't be extrapolated into an assumption that it's going to be a common case.
>
> Indeed, I think it's better to analyze it as a bug in Chrome's and Firefox's Windows input integration than to analyze it as a fundamental unpaired surrogate dependency of the Web Platform.

That's a fair perspective. I also hadn't ever encountered unpaired surrogates until this issue.

I think we still need to have *support* for unpaired surrogates in Rust (for completeness and thoroughness).

However, if the `input` event bug is fixed, then our need for `TextEncoder.containsLoneSurrogates` diminishes dramatically, since we can just use [the `JsString::iter` method](https://github.com/rustwasm/wasm-bindgen/pull/1416) to preserve unpaired surrogates (and `JsString::is_valid_utf16` to check for unpaired surrogates).

This is pretty slow, but since unpaired surrogates are almost nonexistent, I think that's acceptable.

----

> @RReverser while the success case should be fast with either approach and dominated by the string encoding performance and not error handling

For many years `try`/`catch` had a huge performance cost *even in the success case* (in fact, it completely turned off *all* JIT optimizations for any functions that used it!)

However, I just now [tested it](https://jsperf.com/try-catch-performance3), and was pleasantly surprised that you are right: `try`/`catch` only has a ~25% performance cost in the success case. I think that is acceptable for us.

In any case, since it looks like the `input` bug will be fixed directly in browsers, we no longer need `TextEncoder.containsLoneSurrogates`, so I guess my point is moot.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/encoding/issues/174#issuecomment-480059698