<div dir="ltr">On Mon, Feb 27, 2017 at 10:07 PM, Nevin Brackett-Rozinsky via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">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>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></blockquote><div><br></div><div>In fact, I'm greatly dissatisfied with how this proposal captures emoji. Having come up with that scheme, I suspect that it is deficient in subtle or obvious ways that are not yet apparent to me. This is why I have asked for feedback along those lines. Note that for emoji, too, I have deliberately resisted the one-by-one inclusion of certain characters that are excluded by Unicode categories, of which there are a (small) handful. My very strong personal preference, though soundly rejected, would have been to remove the security and forward compatibility headache of support emoji altogether. It does not in my opinion hold its own weight.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><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 <wbr>categorizations should inform and guide out decisions, not constrain them.</div></blockquote><div><br></div><div>Well, now we are talking about overarching principles. The aim of this proposal is in fact to assert that Swift's identifiers and operators should be rationalized in a way that is constrained by Unicode recommendations. Just as Swift aims to provide full support for correct Unicode handling in strings by default, this proposal aims to align the valid characters to current and future Unicode recommendations as tightly as possible. It is anticipated that it should break a very small amount of actual code (if any). It permits Swift to evolve with new developments in Unicode in the future essentially "for free." In exchange we accept imperfections in Unicode as imperfections in Swift. I argue that we should do so because our own imperfections in understanding international character sets will necessarily be greater than that of Unicode experts working systematically.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><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></blockquote><div><br></div><div>Disagree. As mentioned in the proposal, no attempt is made to expand the set of valid identifier characters to include non-emoji pictographs or symbols. If we adopt your approach, infinity and empty set would be the only non-emoji non-"human language" symbols deliberately allowed in identifiers, an approach no more consistent that the previous proposal to include only the cow and dog emoji. The alternative is to go through a vast swath of symbols character-by-character to determine which is sufficiently "noun-like" to be an identifier, as Unicode does not and (as far as I can tell) will never expand UAX#31 to include such symbols among identifiers.</div><div><br></div><div>As I mentioned, it would be also be inconsistent to consider excluding only these two characters and not related characters, such as variations on the infinity symbol, from the set of valid operators. Very quickly, the necessity of doing a character-by-character debate balloons to encompass the entire character set. I continue to believe that this is absolutely the wrong approach.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-HOEnZb"><font color="#888888"><div>Nevin</div>
</font></span><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>