[swift-evolution] Some concerns on custom operators

[Joe Groff]

> 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 <https://github.com/antitypical/Result/issues/191>, link #2 <https://github.com/typelift/SwiftCheck/pull/179>.
> 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.
> Many libraries dealing with custom operators choose to import Runes <https://github.com/thoughtbot/Runes>, which is basically a stockpile of operator declarations. But it conflicts with Result, Swiftx and Operadics.
> 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.
Do you know if bugs have been filed about these issues? IIRC, SE-0077 specified that precedence groups should act like normal named declarations and be scopable. The fact that they aren't sounds like a bug to be fixed.

-Joe
> 
> 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.
> For the mentioned branching, I’m going to post a separate [Pitch] soon.
> _______________________________________________
> 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/20161109/e73f5567/attachment.html>