2016-11-09 22:20 GMT+03:00 John McCall <[email protected]>: > > 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. >
It would also be generally useful for modules that are made use of throughout the project, like logging or those generic operators and collections libraries. I can create a proposal for that. > • 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? Maybe. Anyway, "internal import" can make such conflicts not that much of a problem.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
