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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
