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 >> <[email protected]> wrote: >> on Wed Nov 09 2016, John McCall <[email protected] >> <mailto:[email protected]>> > wrote: >> >>>> On Nov 9, 2016, at 9:25 AM, Anton Zhilin via swift-evolution >>>> <[email protected]> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
