<div class="gmail_quote">On Wed, Jan 25, 2012 at 2:55 PM, Allen Wirfs-Brock <span dir="ltr"><<a href="mailto:allen@wirfs-brock.com">allen@wirfs-brock.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style="word-wrap:break-word"><div><div>The primary intent of the proposal was to extend ES Strings to support a uniform represent of all Unicode characters, including non-BMP.  That means that any Unicode character should occupy exactly one element position within a String value.  Interpreting \u{10ffff} as an UTF-16 encoding does not satisfy that objective.  In particular, under that approach "\{10ffff}".length would be 2 while a uniform character representation should yield a length of 1.</div>

<div><br></div><div>When this proposal was originally floated, the much of debated seemed to be about whether such a uniform character representation was desirable or even useful.  See the thread starting at <a href="https://mail.mozilla.org/pipermail/es-discuss/2011-May/014252.html" target="_blank">https://mail.mozilla.org/pipermail/es-discuss/2011-May/014252.html</a> also <a href="https://mail.mozilla.org/pipermail/es-discuss/2011-May/014316.html" target="_blank">https://mail.mozilla.org/pipermail/es-discuss/2011-May/014316.html</a> and  </div>

</div></div></blockquote></div><div><br></div>That seems highly likely to break existing code that assumes UTF16 representation of JS strings.<br clear="all"><div><br></div>-- <br>John A. Tamplin<br>Software Engineer (GWT), Google<br>