[swift-evolution] [Proposal] Custom operators
antonyzhilin at gmail.com
Mon Apr 4 16:40:42 CDT 2016
Sorry for breaking the thread, next time please mail me a copy :)
Link to the proposal:
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
> 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: '^' --> '*' --> '+',
> 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,
> composing these two is illegal. We need to teach the compiler this
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
> to be allowed here, parsing such expression without ambiguity is a
> non-trivial challenge. So, will it be possible to specify precedence
> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution