<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 31, 2017, at 2:09 PM, Gor Gyolchanyan 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="">So I was thinking the other day (and by "the other day" I mean "It just occurred to me") that Swift's custom operator declaration mechanism is pretty sweet (it's become even sweeter ever since numeric precedence values were replaced with purely relativistic precedence trees). There are currently only two problems with them that grind my operator-declaring endeavors to a painful halt:<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>1. The fact that most punctuation characters on the keyboard (think - ASCII) are reserved, so any custom operator either has to be a long sequence of two or three non-reserved ASCII characters or have to include difficult-to-type unicode punctuation characters.</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>2. The fact that anything that passes as an identifier character (which includes a surprisingly wide array of punctuation characters) is off the table as well.</div></div></div></blockquote><br class=""></div><div>See the 3rd entry of:</div><div><a href="https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md" class="">https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md</a></div><div><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""></body></html>