I think the most important goal is to end up with the right set of operator and identifier characters for *Swift*. The Unicode guidelines are a useful tool for that purpose, and get us a long way toward where we want to be. However at the end of the day we should weigh our success by how well we have done for Swift, not by how rigidly we adhere to Unicode <span style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">recommendations</span>.<div><br></div><div>Our treatment of emoji is a great example: the right thing for Swift is different from the right thing for Unicode, so we choose to do what works best for Swift. This proposal captures that very well.</div><div><br></div><div>Matching what Unicode does should be a means for us, not an end. A stepping stone we can use when it helps. Unicode’s categorizations should inform and guide out decisions, not constrain them.</div><div><br></div><div>With regard to the fact that reclassifying the infinity and empty set symbols would be a breaking change, that is all the more reason to do it now, for Swift 4, before it is too late. Those two characters have come up in every iteration of this discussion on Swift Evolution that I can recall, and I have not heard anyone argue that they ought to be operators. I think it is safe to consider them low-hanging fruit.</div><div><br></div><div>Nevin</div>