<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 Oct 2, 2017, at 10:06 PM, Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</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="">On Oct 2, 2017, at 9:12 PM, David Sweeris via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" 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;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Keep in mind that Swift already goes far above and beyond in terms of operators</div></div></div></div></div></blockquote>Yep, that's is a large part of why I'm such a Swift fan :-D</div></div></div></blockquote><div class=""><br class=""></div><div class="">Fortunately, no one is seriously proposing a major curtailing of the capabilities here, we’re just trying to rationalize the operator set, which is a bit of a mess at present.</div></div></div></div></blockquote><div>I guess I don't really understand why it's currently "a bit of a mess". Maybe I should go take a look at the relevant compiler code to try to get a better understanding of what you're talking about. Or is this purely a matter of finding places where we disagree with Unicode's character classification? If so, I think I'm back at not quite getting it... In any case, I've apparently misunderstood something because I was under the impression that this <i class="">would</i> lead to a "major curtailing".</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" 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;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">in that: (a) it allows overloading of almost all standard operators; (b) it permits the definition of effectively an infinite number of custom operators using characters found in standard operators; (c) it permits the definition of custom precedences for custom operators; and (d) it additionally permits the use of a wide number of Unicode characters for custom operators. Most systems programming languages don't even allow (a), let alone (b) or (c). Even dramatically curtailing (d) leaves Swift with an unusually expansive support for custom operators.</div></div></div></div></div></blockquote></div></div></div></blockquote><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Yes, but many of those custom operators won't have a clear meaning because operators are rarely limited to pre-existing symbols like "++++++++" (which doesn't mean anything at all AFAIK), so operators that are widely known <i class="">within some field</i> probably won't be widely known to the general public, which, IIUC, seems to be your standard for inclusion(?). Please let me know if that's not your position... I hate being misunderstood probably more than the next person, and I wouldn't want to be guilty of that myself.</div></div></div></div></blockquote></div><br class=""><div class="">The approach to operator handling in Swift is very intentional. IMO, it is well known that:</div><div class=""><br class=""></div><div class="">1) Operators can make code significantly easier to understand by reducing noise from complex expressions: writing x.matmul(y) <a href="https://www.python.org/dev/peps/pep-0465/" class="">is insane</a> if you’re doing a lot of matrix multiplies.</div><div class="">2) Operators can be completely opaque to someone who doesn’t know them, and sometimes named functions are more clear.</div><div class="">3) Named functions can also sometimes be completely opaque if you don't know them, e.g. "let x = cholesky(y)"</div><div class="">4) Languages with fixed operator sets that also allow overloading (e.g. C++) end up with those operators being abused.</div><div class="">5) Some code can only be written and maintained by domain experts, and those experts often know the operators.</div><div class=""><br class=""></div><div class="">Swift’s approach is basically to say to users: “ok we allow overloaded operators, but at least if you encounter some operation that you don’t know… you know that you don’t know it”. If you encounter "if ¬x {“ or “a ∩ b” in some source code, at least you can command click, jump to the definition and read what it does: you aren’t misled into thinking that the expression is some familiar thing, but find out later it was overloaded to do something crazy (bitshifts for i/o? really??? :).</div><div class=""><br class=""></div><div class="">Set algebra is an illustrative example, because it is both used by people who are experts and people who are not. As far as policies go, I think it makes sense for Swift libraries to define operator-like things as named functions (e.g. “intersection") and also define operators (“∩”) which can optionally be used in source bases that want them for convenience. The compiler and language cannot know whether a code base is written and maintained by experts who know the symbols and who value their clarity (over the difficulty typing and recognizing them), and this approach allows maintainers of the codebase to pick their own policies.</div></div></div></blockquote><div>Oh, yeah, I can't imagine a situation in which I'd think it'd be a good idea to not define a named function to go along with a unicode operator. I'm mainly concerned that we not limit the people in 5) unless we need to. And to be clear, if we actually need to, then I'm fine with doing that... It's just that -- like I said earlier in this message -- I don't clearly understand why this is a problem. That said, there are multiple people more knowledgable than I am on the topic who are telling me I'm wrong about something that I'm kinda surprised there was disagreement about in the first place... I think it's probably time for me to stop pressing an issue that I apparently don't fully understand and wait to see what's in the actual proposal.</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I do think that Ethan’s suggestion upthread interesting, which suggest considering something like:</div><div class=""> import matrixlib (operators: [ᵀ,·,⊗])</div><div class=""><br class=""></div><div class="">Three concerns I see:</div><div class=""> - Requiring them today would be a source incompatibility with Swift 4</div></div></div></blockquote><div class="">If we leave the current "import everything" behavior as the default, why would it be a source-breaking change? We could also flip the syntax around and write something like "import matrixlib (operators: -[ᵀ,·,⊗])", where we're saying which operators we want to <i class="">not</i> import, because clearly (heh, famous last words in this thread) the default value would the empty list, and an empty list of what not to import implies we should import them all. (I'm not arguing for or against either, just exploring the issue & syntax)</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""> - Multiple modules can define operators, unclear whether this refers to the operator decl or implementations of operators.</div></div></div></blockquote><div class="">If it weren't for precedences, I'd guess it should probably only refer to the implementations, since there's no point (that I can see) of wanting to not import an operator unless you want to use it for something else and the two functions' signatures create ambiguities. Since an operator's precedence is attached to the operator itself rather than the function, it'd probably be better to just pretend it doesn't exist at all.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""> - Imports are per-module, not per-source-file, so this couldn’t be used to “user-partition” the identifier and operator space. It could be a way to make it clear that the user is opting into these explicitly.</div></div></div></blockquote></div><div class="">I haven't followed them as closely as I probably should've, but do the recent threads on submodules change anything WRT this?</div><div class=""><br class=""></div><div class="">- Dave Sweeris</div></body></html>