> On Nov 9, 2016, at 9:25 AM, Anton Zhilin via swift-evolution > <swift-evolution@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? > • Even if operator conflicts are resolved, precedencegroups’ names are > not module-scoped, and don’t support conflict resolution. > • Many libraries decide to just go ahead and prefix > precedencegroups with module name. > • Some developer on Github specifically complained about having > to do this, but I’ve lost the link. Seems like a bug. > • Some precedencegroup names don’t seem perfect to me. This concern may > not be strong enough to make a source-breaking change, though. > • LogicalDisjunctionPrecedence -> DisjunctionPrecedence > • LogicalConjunctionPrecedence -> ConjunctionPrecedence > • BitwiseShiftPrecedence should be renamed to > ExponentiationPrecedence, if we decide not to branch bitwise operators off > arithmetic. Yeah, the time for this feedback was several months ago. John. > • For the mentioned branching, I’m going to post a separate [Pitch] > soon. > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
