<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On 31 Aug 2017, at 23:50, Dave DeLong <<a href="mailto:delong@apple.com" class="">delong@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">wonder if I need to go back to school for a degree in Math just to understand what’s going on.</span></div></blockquote></div><br class=""><div class=""><div class="">To be fair, that’s probably the case. The project is quite extreme (an implementation of System F, I think Robert Widmann did one in Swift as well), and I can’t understand it either regardless of syntax. But the point of the example still stands: To show how extreme you can go with unicode. And from it, spark some discussion.</div><div class=""><br class=""></div><div class="">I agree that using unicode syntax is a higher barrier for entry, which goes against the goal of swift to be an easy to learn language.</div><div class=""><br class=""></div><div class="">Nevertheless, I disagree with your matrix example. We already use things like `+` for “things that we can add together` whatever `add` might mean. So the same operator is used for (Int, Int) -> Int as for (Double, Double) -> Double. I do not think it’s a stretch to expect users to know that matrices are “addable” togethers. Moreover, I would expect that a matrix API provides both an infix operator as well as a named function for manipulating matrices.</div><div class=""><br class=""></div><div class="">Furthermore, I would argue that using `+` for matrices is <i class="">more</i> <i class="">consistent</i> than the current definition of `+`. </div><div class="">Indeed, the operator `+` is both used for combining numbers and combining arrays/strings. The inconsistency comes from the fact that it is expected that `+` is a commutative operator, but concatenation is not a commutative operation. Therefore the semantics of `+` varies depending on the types that it’s used on. And, in my opinion, this inconsistency is to be avoided when dealing with operators. Not to mention that nothing prevent a library to override `+` with any nonsensical behaviour.</div><div class=""><br class=""></div><div class="">Something I could imagine is deprecate operator overloading and constrain them to a single Type. For example, the operator `+` could be constrained to the protocol `Addable` and has the signature `infix func + (Self, Self) -> Self` and is commutative. Similarly, we could have a protocol `Concatenable` which has its own operator (e.g.: ++ ) and is not commutative. (those are secretely `CommutativeMonoid` and `Monoid`). This would allow different operators to represent different semantics and have them (loosely) enforced, so that nobody can declare something unexpected like `func + (Int, Array) -> ()`.</div><div class=""><br class=""></div><div class="">In conclusion, I think that the current state of operators should be improved in some way, regardless of better support for unicode or not. I realise my stance is quite extreme but I think that it is valuable to talk about it.</div></div></body></html>