<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 Nov 9, 2016, at 9:25 AM, Anton Zhilin via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="markdown-here-wrapper" style=""><ol style="margin:1.2em 0px;padding-left:2em" class="">
<li style="margin:0.5em 0px" class=""><div style="margin: 0.5em 0px !important;" class="">Upon implementation of SE-0077 in Swift 3, some libraries started to drop operators entirely: <a href="https://github.com/antitypical/Result/issues/191" class="">link #1</a>, <a href="https://github.com/typelift/SwiftCheck/pull/179" class="">link #2</a>.</div>
<ul style="margin:1.2em 0px;padding-left:2em;margin:0px;padding-left:1em" class="">
<li style="margin:0.5em 0px" class="">Declarations of the same custom operator with different precedence groups create a conflict.</li>
<li style="margin:0.5em 0px" class="">The conflict can be resolved manually, but the resolution has to be made in <em class="">every</em> file that uses the operator, which defeats the reason for using operators in the first place.</li>
<li style="margin:0.5em 0px" class="">This is a part of a larger problem of conflict resolution, for which we don’t currently have a systematic approach.</li>
<li style="margin:0.5em 0px" class="">Many libraries dealing with custom operators choose to import <a href="https://github.com/thoughtbot/Runes" class="">Runes</a>, which is basically a stockpile of operator declarations. But it conflicts with Result, Swiftx and Operadics.</li>
</ul>
</li>
<li style="margin:0.5em 0px" class=""><div style="margin: 0.5em 0px !important;" class="">Even if operator conflicts are resolved, <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="">precedencegroup</code>s’ names are not module-scoped, and don’t support conflict resolution.</div>
<ul style="margin:1.2em 0px;padding-left:2em;margin:0px;padding-left:1em" class="">
<li style="margin:0.5em 0px" class="">Many libraries decide to just go ahead and prefix <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="">precedencegroup</code>s with module name.</li>
<li style="margin:0.5em 0px" class="">Some developer on Github specifically complained about having to do this, but I’ve lost the link.</li></ul></li></ol></div></div></div></blockquote>Do you know if bugs have been filed about these issues? IIRC, SE-0077 specified that precedence groups should act like normal named declarations and be scopable. The fact that they aren't sounds like a bug to be fixed.</div><div><br class=""></div><div>-Joe<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="markdown-here-wrapper" style=""><ol style="margin:1.2em 0px;padding-left:2em" class="" start="2"><li style="margin:0.5em 0px" class=""><ul style="margin:1.2em 0px;padding-left:2em;margin:0px;padding-left:1em" class="">
</ul>
</li>
<li style="margin:0.5em 0px" class=""><div style="margin: 0.5em 0px !important;" class="">Some <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="">precedencegroup</code> names don’t seem perfect to me. This concern may not be strong enough to make a source-breaking change, though.</div>
<ul style="margin:1.2em 0px;padding-left:2em;margin:0px;padding-left:1em" class="">
<li style="margin:0.5em 0px" class=""><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="">LogicalDisjunctionPrecedence</code> -&gt; <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="">DisjunctionPrecedence</code></li>
<li style="margin:0.5em 0px" class=""><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="">LogicalConjunctionPrecedence</code> -&gt; <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="">ConjunctionPrecedence</code></li>
<li style="margin:0.5em 0px" class=""><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="">BitwiseShiftPrecedence</code> should be renamed to <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="">ExponentiationPrecedence</code>, if we decide not to branch bitwise operators off arithmetic.</li>
</ul>
</li>
<li style="margin:0.5em 0px" class=""><div style="margin: 0.5em 0px !important;" class="">For the mentioned branching, I’m going to post a separate <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="">[Pitch]</code> soon.</div>
</li>
</ol>
<div title="MDH:MS4gVXBvbiBpbXBsZW1lbnRhdGlvbiBvZiBTRS0wMDc3IGluIFN3aWZ0IDMsIHNvbWUgbGlicmFy
aWVzIHN0YXJ0ZWQgdG8gZHJvcCBvcGVyYXRvcnMgZW50aXJlbHk6IFtsaW5rICMxXShodHRwczov
L2dpdGh1Yi5jb20vYW50aXR5cGljYWwvUmVzdWx0L2lzc3Vlcy8xOTEpLCBbbGluayAjMl0oaHR0
cHM6Ly9naXRodWIuY29tL3R5cGVsaWZ0L1N3aWZ0Q2hlY2svcHVsbC8xNzkpLjxkaXY+Jm5ic3A7
IC0gRGVjbGFyYXRpb25zIG9mIHRoZSBzYW1lIGN1c3RvbSBvcGVyYXRvciB3aXRoIGRpZmZlcmVu
dCBwcmVjZWRlbmNlIGdyb3VwcyBjcmVhdGUgYSBjb25mbGljdC48L2Rpdj48ZGl2PiZuYnNwOyAt
IFRoZSBjb25mbGljdCBjYW4gYmUgcmVzb2x2ZWQgbWFudWFsbHksIGJ1dCB0aGUgcmVzb2x1dGlv
biBoYXMgdG8gYmUgbWFkZSBpbiAqZXZlcnkqIGZpbGUgdGhhdCB1c2VzIHRoZSBvcGVyYXRvciwg
d2hpY2ggZGVmZWF0cyB0aGUgcmVhc29uIGZvciB1c2luZyBvcGVyYXRvcnMgaW4gdGhlIGZpcnN0
IHBsYWNlLjwvZGl2PjxkaXY+Jm5ic3A7IC0gVGhpcyBpcyBhIHBhcnQgb2YgYSBsYXJnZXIgcHJv
YmxlbSBvZiBjb25mbGljdCByZXNvbHV0aW9uLCBmb3Igd2hpY2ggd2UgZG9uJ3QgY3VycmVudGx5
IGhhdmUgYSBzeXN0ZW1hdGljIGFwcHJvYWNoLjwvZGl2PjxkaXY+Jm5ic3A7IC0gTWFueSBsaWJy
YXJpZXMgZGVhbGluZyB3aXRoIGN1c3RvbSBvcGVyYXRvcnMgY2hvb3NlIHRvIGltcG9ydCBbUnVu
ZXNdKGh0dHBzOi8vZ2l0aHViLmNvbS90aG91Z2h0Ym90L1J1bmVzKSwgd2hpY2ggaXMgYmFzaWNh
bGx5IGEgc3RvY2twaWxlIG9mIG9wZXJhdG9yIGRlY2xhcmF0aW9ucy4gQnV0IGl0IGNvbmZsaWN0
cyB3aXRoIFJlc3VsdCwgU3dpZnR4IGFuZCBPcGVyYWRpY3MuPC9kaXY+PGRpdj48YnI+PC9kaXY+
PGRpdj4yLiBFdmVuIGlmIG9wZXJhdG9yIGNvbmZsaWN0cyBhcmUgcmVzb2x2ZWQsIGBwcmVjZWRl
bmNlZ3JvdXBgcycgbmFtZXMgYXJlIG5vdCBtb2R1bGUtc2NvcGVkLCBhbmQgZG9uJ3Qgc3VwcG9y
dCBjb25mbGljdCByZXNvbHV0aW9uLjwvZGl2PjxkaXY+Jm5ic3A7IC0gTWFueSBsaWJyYXJpZXMg
ZGVjaWRlIHRvIGp1c3QgZ28gYWhlYWQgYW5kIHByZWZpeCBgcHJlY2VkZW5jZWdyb3VwYHMgd2l0
aCBtb2R1bGUgbmFtZS48L2Rpdj48ZGl2PiZuYnNwOyAtIFNvbWUgZGV2ZWxvcGVyIG9uIEdpdGh1
YiBzcGVjaWZpY2FsbHkgY29tcGxhaW5lZCBhYm91dCBoYXZpbmcgdG8gZG8gdGhpcywgYnV0IEkn
dmUgbG9zdCB0aGUgbGluay48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjMuIFNvbWUgYHByZWNl
ZGVuY2Vncm91cGAgbmFtZXMgZG9uJ3Qgc2VlbSBwZXJmZWN0IHRvIG1lLiBUaGlzIGNvbmNlcm4g
bWF5IG5vdCBiZSBzdHJvbmcgZW5vdWdoIHRvIG1ha2UgYSBzb3VyY2UtYnJlYWtpbmcgY2hhbmdl
LCB0aG91Z2guPC9kaXY+PGRpdj4mbmJzcDsgLSBgTG9naWNhbERpc2p1bmN0aW9uUHJlY2VkZW5j
ZWAgLSZndDsgYERpc2p1bmN0aW9uUHJlY2VkZW5jZWA8L2Rpdj7CoCAtIGBMb2dpY2FsQ29uanVu
Y3Rpb25QcmVjZWRlbmNlYCAtJmd0OyBgQ29uanVuY3Rpb25QcmVjZWRlbmNlYDxkaXY+Jm5ic3A7
IC0gYEJpdHdpc2VTaGlmdFByZWNlZGVuY2VgIHNob3VsZCBiZSByZW5hbWVkIHRvIGBFeHBvbmVu
dGlhdGlvblByZWNlZGVuY2VgLCBpZiB3ZSBkZWNpZGUgbm90IHRvIGJyYW5jaCBiaXR3aXNlIG9w
ZXJhdG9ycyBvZmYgYXJpdGhtZXRpYy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjQuIEZvciB0
aGUgbWVudGlvbmVkIGJyYW5jaGluZywgSSdtIGdvaW5nIHRvIHBvc3QgYSBzZXBhcmF0ZSBgW1Bp
dGNoXWAgc29vbi48L2Rpdj4=" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0" class="">​</div></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>