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

[Ross O'Brien]

I've got another suggestion for the bike shedding, and a question.

The naming suggestion: why not simply 'precedes' and 'succeeds'? This
avoids the conjoined words problem. Then you're just writing
'Multiplication { succeeds: Exponentiation, precedes: Addition }'.

The question: this syntax lets you declare a precedence group C and
position it between two groups A and B in the precedence order. If no
existing precedence relationship exists between A and B when this happens
(I'm assuming neither is imported), then creating C between A and B
implicitly creates that relationship.
Suppose wanted to define C's precedence so its operation preceded both A
and B, or succeeded both A and B. Does that require an explicit declaration
of which of A or B takes precedence? If not, would this be legal?:
'precedencegroup C { strongerThan: A, strongerThan: B }'



On Thu, Jun 23, 2016 at 3:52 PM, Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

>
> 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 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
>
>
>
> _______________________________________________
> 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/dbc70db8/attachment.html>