[swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

[Matthew Johnson]

> On Jun 23, 2016, at 8:18 AM, Anton Zhilin via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 1. I've revised the proposal to mostly meet the recommendations.

Thanks continuing to push this forward!  I’m really looking forward to this change and hope the revision is met with acceptance.
 
> 
> https://github.com/Anton3/swift-evolution/blob/master/proposals/0077-
> operator-precedence.md
> 
> 2. My reaction to the rationale:
> 
> precedencegroup Foo {
>   associativity: left
>   strongerThan: Bar
>   weakerThan: Bas
> }
> 
> I agree with colons, but I would prefer above and below. Anyway, core 
> team will have at least one more chance to change their mind.

This is the first time I have encountered the “stronger” and “weaker” terminology in this context.  I am curious about the rationale for preferring those.

FWIW, I also prefer `above` and `below`.  The terms I am most familiar with in discussing precedence are “higher” and “lower” (and is the vocabulary used here: https://en.wikipedia.org/wiki/Order_of_operations <https://en.wikipedia.org/wiki/Order_of_operations> for example).  However, as with `strongerThan` and `weakerThan`, these would require `higherThan` and `lowerThan` in order to read well.   `above` and `below` have a strong relationship to that common vocabulary while being more concise because they do not require including a word that only serves to make our code read like a phrase while offering no information.

> 
> - The proposal states that precedence groups live in a separate 
> namespace from other declarations; however, this is unprecedented in 
> Swift, and leads to significant implementation challenges. The core team 
> recommends that precedence groups exist in the same namespace as all 
> Swift declarations.
> 
> How unfortunate. We will need to discuss naming convention and try not 
> to add too much visual clutter.
> 
> 3. I also have a suggestion to discuss.
> 
> Under "Joining unrelated precedence groups" I see an algorithm that does 
> not match anything I've seen in network theory.
> 
> My suggestion is to make it a warning, not an error. It will reduce the 
> pressure on the language and compilers.
> 
> When we break down precedence hierarchy in a follow-up proposal, 
> developers will be able to use a library that will join precedence 
> groups and make their old code compile, although with warnings.
> 
> - Anton
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160623/0277a520/attachment.html>