[swift-evolution] Some concerns on custom operators
antonyzhilin at gmail.com
Wed Nov 9 11:25:06 CST 2016
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
- 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
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution