Interesting model!

If I understand correctly: this changes the precedence from being based on a 
numeric value, to being represented as a bit of a DAG of precedence groups. A 
precedence group is defined implicitly for each operator, with one group around 
each set of operators where equalTo has been declared.

The groups are lazily evaluated, so if an expression can be resolved without 
ambiguity due to lack of reachability between two individual operators in the 
DAG, there is no issue/error.

Comments:
- I wonder if there are cases in the standard operators which would be better 
modeled as a non-linear chain.  The compiler could warn around usage which is 
defined by operator precedence, but is commonly considered ambiguous or error 
prone. 

For example, if users commonly get confused about the conjunctive and 
disjunctive levels (logical ‘and’ and ‘or’) being different levels with 
precedence, you could just omit the lessThan relationship between the two of 
them. The compiler would then error on ambiguous cases, prompting the user to 
use parenthesis.

- I’d prefer instead of operator precedence groups just being implicit by use 
of #precedence equalTo, that the operators are bound to a group explicitly. 
Something like
#precedence(+, group: “additive”)
#precedence(“additive”, lessThan: “multiplicative”)

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

> On Apr 3, 2016, at 3:36 AM, Антон Жилин via swift-evolution 
> <[email protected]> wrote:
> 
> Swift 2.2 is out, and I restart discussion on syntax for custom operators. I 
> insist that this time we should focus less on linguistic aspects.
> 
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md
>  
> <https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md>
> 

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to