[swift-evolution] Some concerns on custom operators

[John McCall]

> 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.  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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161109/e01caf08/attachment.html>