>> 1) String.prototype.reverse(), as proposed, corrupts supplementary >> characters.
It was agreed at the meeting yesterday that this concern is significant enough, and reverse does not have sufficiently compelling use cases, so should not be included. >> 2) String.prototype.toArray(), as proposed, breaks up the surrogate pairs >> representing supplementary characters and returns each UTF-16 code unit >> separately. This behaviour is consistent with the rest of the Array.prototype functions, and we shouldn't diverge on a case by case basis. We may separately want to consider a set of String APIs that do recognize Unicode characters instead of code units, but that would be a separate Strawman to pursue. >> 3) String.prototype.toArray() ... fills the array with elements defined as >> "the character at position n in S", which according to clause 6 would mean >> 16-bit unsigned values. It seems there needs to be a conversion to the >> intended type of the elements. The resulting array will contain those same "characters", which will each be length 1 strings with a single 16-bit unsigned value. Luke _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
