Hi V8 users, V8 has its own built-in, custom, minimal Unicode library called Unibrow. I am looking into replacing Unibrow with the ICU library. There would be a fallback for non-ICU builds which supports the UTF-8 and UTF-16 encodings for source code, but only gets operations like case mapping right on ASCII. This has a few advantages: - The long-term maintenance burden of our separate Unicode implementation would be removed, freeing up effort to work on other efforts, including better internationalization. - Unibrow has a few long-standing bugs, and sometimes lags the ICU version in the same Chrome build. Replacing it with ICU or ASCII support, depending on build-time flags, would remove these bugs. - The binary size would be slightly reduced, especially on builds without internationalization enabled.
I'm wondering whether anyone who builds without ICU depends on the following features, which I'm proposing to make dependent on ICU: - Unicode-aware case mapping (e.g., String.prototype.toUpperCase()) - JavaScript code with non-ASCII identifiers - Unicode-aware case-insensitive RegExp matching Thanks, Dan -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
