> On Jun 23, 2016, at 8:18 AM, Anton Zhilin via swift-evolution 
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Reply via email to