[swift-evolution] Some concerns on custom operators

[Dave Abrahams]

on Wed Nov 09 2016, John McCall <rjmccall-AT-apple.com> wrote:

>> On Nov 9, 2016, at 1:24 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> on Wed Nov 09 2016, John McCall <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
> wrote:
>> 
>>>> On Nov 9, 2016, at 9:25 AM, Anton Zhilin via swift-evolution <swift-evolution at swift.org> wrote:
>>>> • Upon implementation of SE-0077 in Swift 3, some libraries started to drop operators entirely:
>
>>> link #1, link #2.
>>>> • Declarations of the same custom operator with different precedence groups create a conflict.
>>>> • 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.
>>>> • This is a part of a larger problem of conflict resolution, for which we don’t currently have a
>>> systematic approach.
>>> 
>>> 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.
>>> 
>>>> 		• 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.
>>> 
>>> Won't this just shake itself out pretty soon, assuming these projects
>>> have any interest in interoperating?
>> 
>> This is a well-known library interoperability dynamic, and IMO we can't
>> expect the solution for conflicting libraries to be that you have to get
>> the library authors to communicate with one another.  That effectively
>> fixes nothing for the poor app developer who integrates these libraries.
>
> I agree that we need to solve that problem, which is why I suggested an approach
> for solving that problem in the previous paragraph.  

Sorry if I didn't read carefully enough.

> But it's still reasonable for us as "wardens of the ecosystem" to ask
> library authors to consider how their libraries interoperate with
> their peers.

Sure; that's part of the job of writing a library.

> We can also make a stronger effort to ignore spurious conflicts in the
> language, of course, e.g. by only complaining if conflicting
> precedencegroup declarations would yield different parsing results;
> but that logic would get unworkably complex pretty quick.
>
> John.

-- 
-Dave