[swift-evolution] [Proposal] Custom operators

[Maximilian Hünenberger]

> Am 05.04.2016 um 17:29 schrieb Антон Жилин <antonyzhilin at gmail.com>:
> 
> David Waite stated a major drawback of precedence groups.
> 
> People will often create tiny precedence groups for their modules, and user will find that some of them should actually be the same. They will add precedenceEqualTo, but all these equivalent groups will still exist. This problem cannot occur with transitive precedence propagation. So precedence groups really create more problems than solve.
> 
> - Anton

Do you mean these drawbacks?

"
> However, this may create more issues than it solves (two frameworks creating their own custom operators, putting them in custom precedence groups, and the consumer decides the two precedence groups are really equivalent)
> 
> -DW
"

What is the problem? Changing the relative precedence of external operators in your file? Doesn't the same "problem" occur in your proposal (only with one operator)?

What is the difference between overriding an operator function like this:

func + (l: Int, r: Int) -> Int {
       return 0
}

This can also mess up your code...
I'm sorry if I haven't understood your point.

From the other email:

> I meant, are names `precedenceLessThan`, `precedenceEqualTo` a bit clunky? Maybe:
> 
> associativity(left)
> precedence(lessThan: +)
> precedence(equalTo: +)
> 
> It also solves my concern about dictionary inside braces.

I prefer "precedence(+ lessThan *)". However I don't think it's Swift style since "lessThan" is like an infix operator with letters although the symmetry between "+" and "*" would be nicely handled by such operator.

> Precedence groups have a great benefit of additional symmetry. Transitive precedence propagation, on the other hand, also has benefits:
> 
> 1. It does not introduce new entities, just some rules for compiler
> 2. It does not add new keywords. In your current wording, we have to take precedence and precedenceGroup as keywords, that's why I originally preferred directives

Both 1 and 2 are true but I still prefer to use declarations since they provide exactly one location where to put operators with equal precedence.

By the way "precedence" is already a keyword... One more to go :)

> 3. We actually think in terms of operators, not groups.
> If I want to say that my operator should have the same priority as `+`, I'd rather say that I want it to have priority of plus and minus, not "belong to multiplicative group".
> If I declare <$> and want it to have same priority as <*>, it would be more difficult to invent some name for their group like FunctorManipulator.
> 

I think this deserves more discussion:
Should we allow "precedence(... equalTo ...)" for operators if we have precedence groups?

Such a precedence declaration would be contrary to my argument above: declare equal operator precedences in one place, which is more maintainable.

> On the other hand, in your solution you have a list of global rules and don't really need braces. How about this?
> 
> #precedenceGroup(Additive)
> #precedenceGroup(Multiplicative)
> #precedence(Additive, less, Multiplicative)
> #operator(+, infix, associativity: left, group: Additive)
> #operator(*, infix, associativity: left, group: Multiplicative)
> #operator(<>, infix)
> 
> So precedence group is just a tag that can be used in precedence rules and assigned to operators at declaration.

Although it is consistent with your proposal for me it is too much repetition and "code noise". Compare:

infix operator + { associativity: left }
infix operator * { associativity: left }
infix operator <> {}
precedenceGroup Additive { + }
precedenceGroup Multiplicative { * }
precedence(Additive lessThan Multiplicative)

Which is in my opinion way more readable even without syntax highlighting.


Thank You for sharing Your thoughts which have enriched me! :)

Best regards
- Maximilian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160405/03e08c53/attachment.html>