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 < [email protected]> 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 < > [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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
