<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Dec 17, 2015, at 4:19 PM, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 17, 2015, at 4:15 PM, Greg Parker via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 17, 2015, at 12:14 PM, Ethan Tira-Thompson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div>I wanted to use ‘·’ as a dot-product operator, but it’s not currently defined as an operator character. (<a href="rdar://problem/23930008" class="">rdar://problem/23930008</a> suggested I come here for comment.)<div class=""><br class=""><div class="">Note that dot operator (⋅, U+22C5) is already available for operators and semantically appropriate, but Mac users can conveniently type option-shift-9 to get the middle dot which is a nice feature and consequently it’s more well-known. FWIW, we have U+00B6 (¶) already defined as an operator, this would extend its range by one.</div></div></div></div></blockquote><br class=""></div><div class="">IHNTA, IJWTS "🐶 is an identifier but ⚽︎ is an operator, according to Swift's current rules.”</div></div></div></blockquote></div><br class=""><div class="">I’m not sure what the initialisicms stand for, but any proposal that breaks:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let 🐶🐮 = "moof"</div><div class=""><br class=""></div><div class="">will not be tolerated. :-) :-)</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div></div></div></blockquote></div><br class=""><div class="">Perhaps there’s a way to avoid having to statically classify all of unicode into operator vs. identifier characters?</div><div class=""><br class=""></div><div class="">For example, could this be done dynamically, where the compiler tracks the characters used for each group as it goes, and only complains if it encounters a conflict with a previous declaration?</div><div class=""><br class=""></div><div class="">This does introduce a possibility to have conflicts between a piece of code and an imported API, but the odds of a conflict seem on the scale of other namespace clashes. (Much less IMHO, and even in the case of such a conflict, are we really better suited to have preemptively decided between them?)</div><div class=""><br class=""></div><div class="">If nothing else, debating individual characters like this seems like it will get old really fast, and runs a similar risk of conflicts with pre-existing code on each change. (perhaps greater actually since it’s globally enforced rather than scoped by individual import.)</div><div class=""><br class=""></div><div class="">-Ethan</div><div class=""><br class=""></div></body></html>