<div dir="ltr">Thanks for the response, Dimitri. My comments inline below.<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 18, 2015 at 3:29 AM, Dmitri Gribenko <span dir="ltr">&lt;<a href="mailto:gribozavr@gmail.com" target="_blank">gribozavr@gmail.com</a>&gt;</span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> <br></div><div>One thing to do would be to check the Apple&#39;s ICU implementation, which (I think) implements some extra handling for UTR #51 (<a href="http://opensource.apple.com/release/os-x-1011/" target="_blank">http://opensource.apple.com/release/os-x-1011/</a>) to see how it deals with this, whether it introduces tailoring, and if so, in what way.</div></div></div></div></blockquote><div><br></div><div> I will look into that. I had always thought that would have been part of Core Text, and not open sourced. It is great to know that it is open-sourced.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>My primary concern with the fix in the PR is that it seems to change the segmentation behavior for other sequences.  The grapheme cluster segmentation algorithm is local and stateless.  It only looks at two adjacent Unicode scalars.  This means that adding a rule like &quot;ZWJ no_boundary Emoji&quot; will affect all sequences, even those that are not a grouping as defined in UTR #51 (for example, &quot;Latin letter, ZWJ, Emoji&quot;: the three scalars would be grouped).</div></div></div></div></blockquote><div><br></div><div>Apologies, I forgot to mention that disadvantage. It does change the segmentation behavior for other sequences, which was one of the reasons I was on the fence about whether this should go through the swift-evolution process.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>This is the same issue as multiple flags pasted together (which are represented as regional indicator characters).  The current algorithm just does not have enough information to split them apart, it needs to look at a wider part of the string.</div></div></div></div></blockquote><div><br></div><div>I could be reading the Unicode standard incorrectly, but it appears that this might be the intended behavior for the flag characters. I definitely agree that it&#39;s not ideal.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I would be much happier with a solution only changed the segmentation for the cases covered by the TR, but I understand it might have performance implications.  I think we should try to add such a tailoring, and benchmark it.</div></div></div></div></blockquote><div><br></div><div>Just so that I understand what you mean by tailoring, you mean switching to a possibly stateful algorithm which can consider more than just two adjacent characters when grouping, right?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The change that adds the first tailoring to the algorithm might be significant enough.  But I think it would be a question of whether we want any tailoring at all, not about specific tailoring.</div></div></div></div></blockquote><div><br></div><div>Thanks for the clarification. Just to be sure, if this change wasn&#39;t as problematic, but still changed the behavior of Swift.String, you&#39;re saying it would not be important enough for swift-evolution? As a concrete example, if I was just proposing to fix the skin tone emoji, but not the SWJ sequences, would it be considered just a bug fix?</div></div></div></div>