<div dir="ltr">Would it make sense to allow some kind of operator aliasing on import,
so that developers can at least work-around library conflicts?</div><br><div class="gmail_quote"><div dir="ltr">On Wed, 9 Nov 2016 at 21:59 Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
on Wed Nov 09 2016, John McCall <rjmccall-AT-apple.com> wrote:<br class="gmail_msg">
<br class="gmail_msg">
>> On Nov 9, 2016, at 1:24 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
>> on Wed Nov 09 2016, John McCall <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>>><br class="gmail_msg">
> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>>>> On Nov 9, 2016, at 9:25 AM, Anton Zhilin via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
>>>> • Upon implementation of SE-0077 in Swift 3, some libraries started to drop operators entirely:<br class="gmail_msg">
><br class="gmail_msg">
>>> link #1, link #2.<br class="gmail_msg">
>>>> • Declarations of the same custom operator with different precedence groups create a conflict.<br class="gmail_msg">
>>>> • The conflict can be resolved manually, but the resolution has to be made in every file that uses<br class="gmail_msg">
>>> the operator, which defeats the reason for using operators in the first place.<br class="gmail_msg">
>>>> • This is a part of a larger problem of conflict resolution, for which we don’t currently have a<br class="gmail_msg">
>>> systematic approach.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> It makes sense to me to provide a more module-wide conflict resolution<br class="gmail_msg">
>>> mechanism. Maybe we can have some sort of "internal export" mechanism<br class="gmail_msg">
>>> where a file can introduce imports into other files within a project.<br class="gmail_msg">
>>><br class="gmail_msg">
>>>> • Many libraries dealing with custom operators choose<br class="gmail_msg">
>>>> to import Runes, which is basically a stockpile of operator<br class="gmail_msg">
>>>> declarations. But it conflicts with Result, Swiftx and Operadics.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> Won't this just shake itself out pretty soon, assuming these projects<br class="gmail_msg">
>>> have any interest in interoperating?<br class="gmail_msg">
>><br class="gmail_msg">
>> This is a well-known library interoperability dynamic, and IMO we can't<br class="gmail_msg">
>> expect the solution for conflicting libraries to be that you have to get<br class="gmail_msg">
>> the library authors to communicate with one another. That effectively<br class="gmail_msg">
>> fixes nothing for the poor app developer who integrates these libraries.<br class="gmail_msg">
><br class="gmail_msg">
> I agree that we need to solve that problem, which is why I suggested an approach<br class="gmail_msg">
> for solving that problem in the previous paragraph.<br class="gmail_msg">
<br class="gmail_msg">
Sorry if I didn't read carefully enough.<br class="gmail_msg">
<br class="gmail_msg">
> But it's still reasonable for us as "wardens of the ecosystem" to ask<br class="gmail_msg">
> library authors to consider how their libraries interoperate with<br class="gmail_msg">
> their peers.<br class="gmail_msg">
<br class="gmail_msg">
Sure; that's part of the job of writing a library.<br class="gmail_msg">
<br class="gmail_msg">
> We can also make a stronger effort to ignore spurious conflicts in the<br class="gmail_msg">
> language, of course, e.g. by only complaining if conflicting<br class="gmail_msg">
> precedencegroup declarations would yield different parsing results;<br class="gmail_msg">
> but that logic would get unworkably complex pretty quick.<br class="gmail_msg">
><br class="gmail_msg">
> John.<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
-Dave<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>