[swift-evolution] Some concerns on custom operators

[Jay Abbott]

Would it make sense to allow some kind of operator aliasing on import, so
that developers can at least work-around library conflicts?

On Wed, 9 Nov 2016 at 21:59 Dave Abrahams via swift-evolution <
swift-evolution at swift.org> wrote:

>
> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161110/cc6a7463/attachment.html>