<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-11-09 22:20 GMT+03:00 John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> On Nov 9, 2016, at 9:25 AM, Anton Zhilin via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
</span>> • Upon implementation of SE-0077 in Swift 3, some libraries started to drop operators entirely: link #1, link #2.<br>
<span class="">> • Declarations of the same custom operator with different precedence groups create a conflict.<br>
> • The conflict can be resolved manually, but the resolution has to be made in every file that uses the operator, which defeats the reason for using operators in the first place.<br>
> • This is a part of a larger problem of conflict resolution, for which we don’t currently have a systematic approach.<br>
<br>
</span>It makes sense to me to provide a more module-wide conflict resolution mechanism. Maybe we can have some sort of "internal export" mechanism where a file can introduce imports into other files within a project.<br></blockquote><div><br></div><div>It would also be generally useful for modules that are made use of throughout the project, like logging or those generic operators and collections libraries. I can create a proposal for that.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> • Many libraries dealing with custom operators choose to import Runes, which is basically a stockpile of operator declarations. But it conflicts with Result, Swiftx and Operadics.<br>
<br>
Won't this just shake itself out pretty soon, assuming these projects have any interest in interoperating?</blockquote><div><br></div><div>Maybe. Anyway, "internal import" can make such conflicts not that much of a problem.</div></div></div></div>