<div class="gmail_quote">On 20 February 2012 16:00, 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">

My sense is that there are a fairly large variety of string data types could be use the existing ES5 string type as a target type and for which many of the String.prototuype.* methods would function just fine  The reason is that most of the ES5 methods don't impose this sort of semantic restriction of string elements.<br>
<div class="im"></div></blockquote><div class="im"><br>To pick one out of a hat, it might be nice to be able to use non-Unicode encodings, like GB 18030 or BIG5, and be able to use regexp methods on them when the BRS is on. (I'm struggling to find a really real real-world use-case, though)<br>
<br>Observation -- disallowing otherwise "legal" Unicode strings because they contain code points d800-dfff has very concrete implementation benefits: it's possible to use UTF-16 to represent the String's backing store.  Without this concession, I fear it may not be possible to implement BRS-on without using a UTF-8 or full code point  backing store (or some non-standard invention).<br>
<br>Maybe the answer is to consider (shudder) adding String-like utility functions to the TypedArrays?  FWIW, CommonJS tried to go down this path and it turned out to be a lot of work for very little benefit (if any). <br>
<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But with the BRS flipped it would have to censor C "strings" passed to JS to ensure that unmatched surrogate pairs are present.<br>
</blockquote><div><br>Only if the C strings are wide-character strings.  8-bit char strings are fine, they map right onto Latin-1 in native Unicode as well as the UTF-16 and UCS-2 encodings.<br><br></div>Wes<br><br></div>
-- <br>Wesley W. Garland<br>Director, Product Development<br>PageMail, Inc.<br>+1 613 542 2787 x 102<br>