[swift-evolution] [Draft] Resolving operator precedence conflicts

[Chris Lattner]

> On Mar 9, 2016, at 11:15 AM, Sean Heber via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Isn’t this essentially describing it’s expression-ness? Why not just use “expression” like:
> 
> expression: infix
> expression: postfix
> expression: prefix

Are any of these proposals *better* than “infix operator + {“ ?

I’m not claiming that the body of the operator declaration is great, but one nice thing about it is that the required terms are part of the decl modifier, the optional gunk is in the body, and it reads well.

-Chris


> 
> l8r
> Sean
> 
> 
>> On Mar 9, 2016, at 1:12 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On Mar 9, 2016, at 12:10 PM, Charles Kissinger <crk at akkyra.com> wrote:
>>> 
>>> 
>>>> On Mar 8, 2016, at 1:52 PM, Austin Zheng <austinzheng at gmail.com> wrote:
>>>> 
>>>> 'Fixity' already has a non-technical meaning ("the state of being unchanged and permanent"), and an unrelated technical one (a synonym for associativity; search "assocativity fixity operator" for examples). If we're using it in this different way, I respectfully submit that we should reconsider.
>>> 
>>> You are correct, of course, but a subset of computer scientists have been abusing the term in this way for at least a couple of decades. Their novel usage of “fixity” now has a degree of fixity, so it may be too late to fix "fixity".
>> 
>> It's become a termity of art.
>> 
>> -- E
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution