[swift-evolution] [Proposal] Custom operators

[Антон Жилин]

Sorry for breaking the thread, next time please mail me a copy :)
Link to the proposal:
https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md

1.  I strongly agree that the numeric precedence system is not great. From
>     a implementation point of view, the way to specify them in your
> proposal
>     essentially gave all visible operators a partial order, in which we can
>     draw a directed gragh with operators being the nodes and their relation
>     being arcs. A part of the graph might look like: '^' --> '*' --> '+',
> the
>     nodes being the math operators. We can tell '*' has a higher precedence
>     than '+', '^' has a higher precedence than '*' and '+', by follwing the
>     arcs. If one operator is not reachable from another, and vice versa,
> then
>     composing these two is illegal. We need to teach the compiler this
> concept.
>

Right, that semantics was actually the main driver of the proposal.

2.  Currently, it's not possible to specify precedence for pre- and postfix
>     operators. Chris Lattner has mentioned that the
>     following result is not desirable:
>         ∆x + y
>     … where ∆ has a lower precendence than + while it's required to have no
>     space between ∆ and the operand. My understanding is that if spaces
> were
>     to be allowed here, parsing such expression without ambiguity is a
>     non-trivial challenge. So, will it be possible to specify precedence
> for
>     pre/postfix operators under your proposal?
>

No, I currently leave prefix and postfix operators unchanged (apart from
syntax shuffling). I will add this as a future direction.
Prefix and postfix operators would behave the same as infix, but have
higher precedence than any infix operator by default.
This feature, if added, would be non-breaking.


> 3.  It may be a good exercise to work out how would each of the builtin
>     operators would be defined with this change and mention it (not the
> entire
>     definition, but the fact that it's possible, or reasons why it produces
>     any difference) in the proposal.


Operators `is`, `as`, `as?`, `as!`, which are not actually Swift custom
operators (they contain letters), will not participate in this exercise.
(Let's not discuss allowing letters in operators here.)
That being said, great idea. I will add example declarations of standard
library operators.

 - Anton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160405/0a9b944d/attachment.html>