[Review] SE-0077: Improved operator declarations

Evolution Announcements
1

Hello Swift community,

The review of "SE-0077: Improved operator declarations" begins now and runs through May 23. The proposal is available here:

  swift-evolution/0077-operator-precedence.md at master · apple/swift-evolution · GitHub

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thank you,

-Chris Lattner
Review Manager

2

        * What is your evaluation of the proposal?

Generally in favor. To indulge in a little bikeshedding:

* `precedencegroup` defines both associativity and precedence, so the
naming isn't great. Maybe `operatorgroup`?
* I'm not sure about the parentheses used between the braces. To me, it
would fit better with the language to use colons.
* It may be confusing that relative precedence levels are themselves
described using operators or words that describe operators. I'd suggest
simpler words that aren't self-referential, such as "above" and "below".

So to put it all together, here's the color of my bikeshed:

```
operatorgroup Comparative {
  associativity: left,
  precedence: above(LogicalAnd)
}

···

        * Is the problem being addressed significant enough to warrant a
change to Swift?
        * Does this proposal fit well with the feel and direction of Swift?
        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

* What is your evaluation of the proposal?
+1
        * Is the problem being addressed significant enough to warrant a
change to Swift?
Yes. Definitely. Operator overloading is currently fine in only the
simplest of cases.
        * Does this proposal fit well with the feel and direction of Swift?
I think so, yes.
        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
No
        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

I followed the original thread and have been wrangling precedence for a
while now.

One problem that I have encountered with operators that I think still needs
solving is operators from different libraries colliding with regard to
precedence.

`^` is the example that bit me most recently. Swift has one with left
fixity at 160. I wanted to overload it with right fixity for math
operators. The only way that I have thought involves
- precedence groups are tied to a module
- overloads in modules are tied to specific precedence groups.

I have *not a clue* about how feasible this solution is, but it would allow
greater flexibility and, at least in my opinion, more understandable
behavior. Attempting to overload `^` right now, especially with right
fixity, results in confusing behavior.

···

On Tue, May 17, 2016 at 11:30 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0077: Improved operator declarations" begins now and
runs through May 23. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of Swift.
When writing your review, here are some questions you might want to answer
in your review:

        * What is your evaluation of the proposal?
        * Is the problem being addressed significant enough to warrant a
change to Swift?
        * Does this proposal fit well with the feel and direction of Swift?
        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

4

* What is your evaluation of the proposal?
+1. Although I would prefer something like:

precedence(greaterThan: LogicalAnd)

to:

precedence(> LogicalAnd)

I think the latter is more difficult to read, and I just find the idea of
using an operator in an operator/precendencegroup definition strange.

        * Is the problem being addressed significant enough to warrant a
change to Swift?
Yes
        * Does this proposal fit well with the feel and direction of Swift?
Yes. Magical numbers are definitely not used elsewhere in the language.
        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
N/A
        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
Read the proposal

···

On Tue, May 17, 2016 at 11:30 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0077: Improved operator declarations" begins now and
runs through May 23. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of Swift.
When writing your review, here are some questions you might want to answer
in your review:

        * What is your evaluation of the proposal?
        * Is the problem being addressed significant enough to warrant a
change to Swift?
        * Does this proposal fit well with the feel and direction of Swift?
        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

5

  * What is your evaluation of the proposal?

I like this proposal, except for the `precedencegroup` syntax, which I think is a bit overwrought. Rather than this proposal's:

  precedencegroup Multiplicative {
    associativity(left)
    precedence(> Additive)
  }

I would prefer to see:

  precedence Multiplicative > Additive left

(Or possibly, if the `left` is deemed too inexplicable by itself, `associativity(left)`.) I don't really think the `precedence` keyword or the curly brackets bring much to the declaration, and dropping them allows us to replace the awkward compound `precedencegroup` with the shorter and equally explanatory `precedence`.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes. The numeric precedence levels are a significant wart, an impedance to both reading the standard library and implementing new custom operators.

  * Does this proposal fit well with the feel and direction of Swift?

Yes. Magic numbers are un-Swifty.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

The only language I know which has equivalently powerful custom operator specification is Perl 6. When you define a new operator in Perl 6, you're asked to declare it `is tighter`, `is looser`, or `is equiv` to another operator. `tighter` and `looser` both introduce a new precedence level between the operator you specified and the next closest existing precedence level.

The Swift solution seems better because it asks you to design your precedence hierarchy first and then assign operators to its levels. It also allows for two operators to have no precedence relative to each other, so they have to be parenthesized.

However, one good thing about the Perl 6 solution is that it lets you introduce new precedence levels between the existing ones. It's not clear to me if this proposal allows that, and if so, how. (I don't believe any of the examples demonstrate that.)

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading.

···

--
Brent Royal-Gordon
Architechies

6

Hello Swift community,

The review of "SE-0077: Improved operator declarations" begins now and runs through May 23. The proposal is available here:

        https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md

        * What is your evaluation of the proposal?

I didn't follow much of the thread for this but from the description
of the proposal I can see how it adds clarity and understanding to
code. I really cannot tell the precedence of an operator I declared in
certain expressions because those precedence number don't make much
sense. The idea of describing the precedence of the operator compared
to other groups of operators seems to add a lot more of understanding
to my code. Just forgive me if I didn't see this but I expect that I
cannot declare an operator belonging to more than one group or compare
to more than one group for precedence (thou I see some situations
being able to asset precedence against more than one group could be
useful).

        * Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

        * Does this proposal fit well with the feel and direction of Swift?

Yes.

        * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

C# allowed for operator overloading but not declaring new operators
thus all precedence was already defined by the language.

        * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick reading.

7

  * What is your evaluation of the proposal?

+1. A major improvement over the current system. I’m fine with the suggested syntax in general. I’ll be using it rarely enough that it won’t bother me what is eventually settled on.

By the way, in the future directions version of the BitwiseShift group we have

     members(<<, >>)

Is that a typo?

Also, just to confirm that my understanding of how this will work is correct, the proposal seems to suggest that future directions definitions of the bitwise operators will forbid combining bitwise operators in expressions with arithmetic operators e.g.

     a << b + c

will be illegal because there is no relationship defined between the additive group and the bitwise groups (when it comes up for review, I will definitely be opposed to that, but it doesn’t affect my assessment of this proposal).
  

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes

  * Does this proposal fit well with the feel and direction of Swift?

Yes

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I’ve used operator overloading in both C++ and C#. You can’t define new operators in C#, so the problem does not exist there and I can’t remember how it worked in C++ because the experience seems to have been erased from my mind.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the review, skimmed the three.

···

On 18 May 2016, at 04:30, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

8

The transitivity rule plus the ability to define precedence relationships in both directions on a new precedence group allows a new precedence group to create a precedence relationship between existing unrelated precedence groups. This should be forbidden.

What's the purpose of equality relationships between precedence groups?

Your proposal should call out the special treatment of the Assignment and Ternary groups.

John.

···

On May 17, 2016, at 8:30 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
Hello Swift community,

The review of "SE-0077: Improved operator declarations" begins now and runs through May 23. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md

9

Any updates about the status of this review?

Thanks,
Brandon

···

On May 17, 2016, at 11:30 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0077: Improved operator declarations" begins now and runs through May 23. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

10

I like this proposal but I believe the syntax could be better.

I think this would read more naturally:

precedence Multiplicative { above Additive left }

I would suggest using above, below, equalto, for the precedence values.

I think it reads more naturally and, like others have said, I find it odd that a operator is used inside an operator declaration.

I love how clean current operator declarations look and would like to see that preserved somewhat.

Brandon

···

Sent from my iPad

11

Inline:

The transitivity rule plus the ability to define precedence relationships
in both directions on a new precedence group allows a new precedence group
to create a precedence relationship between existing unrelated precedence
groups. This should be forbidden.

Agreed, although there is an alternate solution to allow global-scope
relationship definition.
Trying to write it formally:

====begin====
Precedence relationships that, by transitivity rule, create relationship
between two imported groups, is an error. Example:

// Module X
precedencegroup A { }
precedencegroup C { }

// Module Y
import X
precedencegroup B { precedence(> A) precedence(< C) }

This results in compilation error "B uses transitivity to define
relationship between imported groups A and C".
The rationale behind this is that otherwise one can create relationships
between standard precedence groups that are confusing for the reader.
====end====

What's the purpose of equality relationships between precedence groups?

Agreed, will remove.

Your proposal should call out the special treatment of the Assignment and
Ternary groups.

Do you mean that most operators should define greater precedence than
Assignment / Ternary? Or there should be some other special treatment?

- Anton

···

2016-05-20 20:58 GMT+03:00 John McCall <rjmccall@apple.com>:

12

Inline:

2016-05-20 20:58 GMT+03:00 John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>>:
The transitivity rule plus the ability to define precedence relationships in both directions on a new precedence group allows a new precedence group to create a precedence relationship between existing unrelated precedence groups. This should be forbidden.

Agreed, although there is an alternate solution to allow global-scope relationship definition.
Trying to write it formally:

====begin====
Precedence relationships that, by transitivity rule, create relationship between two imported groups, is an error. Example:

// Module X
precedencegroup A { }
precedencegroup C { }

// Module Y
import X
precedencegroup B { precedence(> A) precedence(< C) }

This results in compilation error "B uses transitivity to define relationship between imported groups A and C".
The rationale behind this is that otherwise one can create relationships between standard precedence groups that are confusing for the reader.
====end====

Seems good to me.

What's the purpose of equality relationships between precedence groups?

Agreed, will remove.

Ok.

Your proposal should call out the special treatment of the Assignment and Ternary groups.

Do you mean that most operators should define greater precedence than Assignment / Ternary? Or there should be some other special treatment?

Just that they have implicit members.

John.

···

On May 20, 2016, at 1:25 PM, Антон Жилин <antonyzhilin@gmail.com> wrote:

13

Inline:

2016-05-20 20:58 GMT+03:00 John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>>:
The transitivity rule plus the ability to define precedence relationships in both directions on a new precedence group allows a new precedence group to create a precedence relationship between existing unrelated precedence groups. This should be forbidden.

Agreed, although there is an alternate solution to allow global-scope relationship definition.
Trying to write it formally:

====begin====
Precedence relationships that, by transitivity rule, create relationship between two imported groups, is an error. Example:

// Module X
precedencegroup A { }
precedencegroup C { }

// Module Y
import X
precedencegroup B { precedence(> A) precedence(< C) }

This results in compilation error "B uses transitivity to define relationship between imported groups A and C".
The rationale behind this is that otherwise one can create relationships between standard precedence groups that are confusing for the reader.
====end====

Seems good to me.

Would this be allowed if Module X already defined precedence group C > A (it would not be defining a *new* relationship between A and C in that case)?

···

On May 20, 2016, at 3:51 PM, John McCall <rjmccall@apple.com> wrote:

On May 20, 2016, at 1:25 PM, Антон Жилин <antonyzhilin@gmail.com <mailto:antonyzhilin@gmail.com>> wrote:

What's the purpose of equality relationships between precedence groups?

Agreed, will remove.

Ok.

Your proposal should call out the special treatment of the Assignment and Ternary groups.

Do you mean that most operators should define greater precedence than Assignment / Ternary? Or there should be some other special treatment?

Just that they have implicit members.

John.

14

Yes, in this case it should be allowed, because this relationship already
existed in imported modules. I will add that, too, thanks!

- Anton

···

2016-05-21 0:01 GMT+03:00 Matthew Johnson <matthew@anandabits.com>:

On May 20, 2016, at 3:51 PM, John McCall <rjmccall@apple.com> wrote:

On May 20, 2016, at 1:25 PM, Антон Жилин <antonyzhilin@gmail.com> wrote:
Inline:

2016-05-20 20:58 GMT+03:00 John McCall <rjmccall@apple.com>:

The transitivity rule plus the ability to define precedence relationships
in both directions on a new precedence group allows a new precedence group
to create a precedence relationship between existing unrelated precedence
groups. This should be forbidden.

Agreed, although there is an alternate solution to allow global-scope
relationship definition.
Trying to write it formally:

====begin====
Precedence relationships that, by transitivity rule, create relationship
between two imported groups, is an error. Example:

// Module X
precedencegroup A { }
precedencegroup C { }

// Module Y
import X
precedencegroup B { precedence(> A) precedence(< C) }

This results in compilation error "B uses transitivity to define
relationship between imported groups A and C".
The rationale behind this is that otherwise one can create relationships
between standard precedence groups that are confusing for the reader.

====end====

Seems good to me.

Would this be allowed if Module X already defined precedence group C > A
(it would not be defining a *new* relationship between A and C in that
case)?

What's the purpose of equality relationships between precedence groups?

Agreed, will remove.

Ok.

Your proposal should call out the special treatment of the Assignment and

Ternary groups.

Do you mean that most operators should define greater precedence than
Assignment / Ternary? Or there should be some other special treatment?

Just that they have implicit members.

John.

15

Yes, in this case it should be allowed, because this relationship already existed in imported modules. I will add that, too, thanks!

Cool.

What is the latest syntax you are using? Did you consider any of the lighter weight options? That subthread died without conclusion (unless I missed something somehow).

···

On May 20, 2016, at 4:22 PM, Антон Жилин <antonyzhilin@gmail.com> wrote:

- Anton

2016-05-21 0:01 GMT+03:00 Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>>:

On May 20, 2016, at 3:51 PM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On May 20, 2016, at 1:25 PM, Антон Жилин <antonyzhilin@gmail.com <mailto:antonyzhilin@gmail.com>> wrote:
Inline:

2016-05-20 20:58 GMT+03:00 John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>>:
The transitivity rule plus the ability to define precedence relationships in both directions on a new precedence group allows a new precedence group to create a precedence relationship between existing unrelated precedence groups. This should be forbidden.

Agreed, although there is an alternate solution to allow global-scope relationship definition.
Trying to write it formally:

====begin====
Precedence relationships that, by transitivity rule, create relationship between two imported groups, is an error. Example:

// Module X
precedencegroup A { }
precedencegroup C { }

// Module Y
import X
precedencegroup B { precedence(> A) precedence(< C) }

This results in compilation error "B uses transitivity to define relationship between imported groups A and C".
The rationale behind this is that otherwise one can create relationships between standard precedence groups that are confusing for the reader.
====end====

Seems good to me.

Would this be allowed if Module X already defined precedence group C > A (it would not be defining a *new* relationship between A and C in that case)?

What's the purpose of equality relationships between precedence groups?

Agreed, will remove.

Ok.

Your proposal should call out the special treatment of the Assignment and Ternary groups.

Do you mean that most operators should define greater precedence than Assignment / Ternary? Or there should be some other special treatment?

Just that they have implicit members.

John.

16

My working version is still the one in the proposal, but I'm planning to
add the alternative versions we discussed, including your and Brent's
variants.

IMHO, original version is heavy, but clear (not to confuse with "clean").
Your lighter version looks more clean, but somewhat less consistent and
more free in terms of grammar.

Also, I've got another version, which is considerably ligher than current
one, while being as structured:

precedence Multiplicative {
    associativity(left)
    above(Additive)
    below(Exponentiative)
}

- Anton

···

2016-05-21 0:25 GMT+03:00 Matthew Johnson <matthew@anandabits.com>:

On May 20, 2016, at 4:22 PM, Антон Жилин <antonyzhilin@gmail.com> wrote:

Yes, in this case it should be allowed, because this relationship already
existed in imported modules. I will add that, too, thanks!

Cool.

What is the latest syntax you are using? Did you consider any of the
lighter weight options? That subthread died without conclusion (unless I
missed something somehow).

- Anton

2016-05-21 0:01 GMT+03:00 Matthew Johnson <matthew@anandabits.com>:

On May 20, 2016, at 3:51 PM, John McCall <rjmccall@apple.com> wrote:

On May 20, 2016, at 1:25 PM, Антон Жилин <antonyzhilin@gmail.com> wrote:
Inline:

2016-05-20 20:58 GMT+03:00 John McCall <rjmccall@apple.com>:

The transitivity rule plus the ability to define precedence
relationships in both directions on a new precedence group allows a new
precedence group to create a precedence relationship between existing
unrelated precedence groups. This should be forbidden.

Agreed, although there is an alternate solution to allow global-scope
relationship definition.
Trying to write it formally:

====begin====
Precedence relationships that, by transitivity rule, create relationship
between two imported groups, is an error. Example:

// Module X
precedencegroup A { }
precedencegroup C { }

// Module Y
import X
precedencegroup B { precedence(> A) precedence(< C) }

This results in compilation error "B uses transitivity to define
relationship between imported groups A and C".
The rationale behind this is that otherwise one can create relationships
between standard precedence groups that are confusing for the reader.

====end====

Seems good to me.

Would this be allowed if Module X already defined precedence group C > A
(it would not be defining a *new* relationship between A and C in that
case)?

What's the purpose of equality relationships between precedence groups?

Agreed, will remove.

Ok.

Your proposal should call out the special treatment of the Assignment and

Ternary groups.

Do you mean that most operators should define greater precedence than
Assignment / Ternary? Or there should be some other special treatment?

Just that they have implicit members.

John.

17

My working version is still the one in the proposal, but I'm planning to
add the alternative versions we discussed, including your and Brent's
variants.

IMHO, original version is heavy, but clear (not to confuse with "clean").
Your lighter version looks more clean, but somewhat less consistent and
more free in terms of grammar.

Also, I've got another version, which is considerably ligher than current
one, while being as structured:

precedence Multiplicative {
    associativity(left)
    above(Additive)
    below(Exponentiative)
}

Why not:

precedence Multiplicative {
    associativity left
    above Additive
    below Epxonentiative
}

Just seeing if removing the parens reduces some of the noise.

Sorry if I missed this suggestion earlier and it was denied :P

+1 to this, or a version with colons and commas

···

On Fri, May 20, 2016 at 5:06 PM, Brandon Knope via swift-evolution < swift-evolution@swift.org> wrote:

On May 20, 2016, at 5:56 PM, Антон Жилин via swift-evolution < > swift-evolution@swift.org> wrote:

Brandon

- Anton

2016-05-21 0:25 GMT+03:00 Matthew Johnson <matthew@anandabits.com>:

On May 20, 2016, at 4:22 PM, Антон Жилин <antonyzhilin@gmail.com> wrote:

Yes, in this case it should be allowed, because this relationship already
existed in imported modules. I will add that, too, thanks!

Cool.

What is the latest syntax you are using? Did you consider any of the
lighter weight options? That subthread died without conclusion (unless I
missed something somehow).

- Anton

2016-05-21 0:01 GMT+03:00 Matthew Johnson <matthew@anandabits.com>:

On May 20, 2016, at 3:51 PM, John McCall <rjmccall@apple.com> wrote:

On May 20, 2016, at 1:25 PM, Антон Жилин <antonyzhilin@gmail.com> wrote:
Inline:

2016-05-20 20:58 GMT+03:00 John McCall <rjmccall@apple.com>:

The transitivity rule plus the ability to define precedence
relationships in both directions on a new precedence group allows a new
precedence group to create a precedence relationship between existing
unrelated precedence groups. This should be forbidden.

Agreed, although there is an alternate solution to allow global-scope
relationship definition.
Trying to write it formally:

====begin====
Precedence relationships that, by transitivity rule, create relationship
between two imported groups, is an error. Example:

// Module X
precedencegroup A { }
precedencegroup C { }

// Module Y
import X
precedencegroup B { precedence(> A) precedence(< C) }

This results in compilation error "B uses transitivity to define
relationship between imported groups A and C".
The rationale behind this is that otherwise one can create relationships
between standard precedence groups that are confusing for the reader.

====end====

Seems good to me.

Would this be allowed if Module X already defined precedence group C > A
(it would not be defining a *new* relationship between A and C in that
case)?

What's the purpose of equality relationships between precedence groups?

Agreed, will remove.

Ok.

Your proposal should call out the special treatment of the Assignment

and Ternary groups.

Do you mean that most operators should define greater precedence than
Assignment / Ternary? Or there should be some other special treatment?

Just that they have implicit members.

John.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

18

My working version is still the one in the proposal, but I'm planning to add the alternative versions we discussed, including your and Brent's variants.

IMHO, original version is heavy, but clear (not to confuse with "clean"). Your lighter version looks more clean, but somewhat less consistent and more free in terms of grammar.

Also, I've got another version, which is considerably ligher than current one, while being as structured:

precedence Multiplicative {
    associativity(left)
    above(Additive)
    below(Exponentiative)
}

In this case I think clear and clean are one and the same. The parentheses feel arbitrarily noisy to me. What purpose do they serve?

···

On May 20, 2016, at 4:56 PM, Антон Жилин <antonyzhilin@gmail.com> wrote:

- Anton

2016-05-21 0:25 GMT+03:00 Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>>:

On May 20, 2016, at 4:22 PM, Антон Жилин <antonyzhilin@gmail.com <mailto:antonyzhilin@gmail.com>> wrote:

Yes, in this case it should be allowed, because this relationship already existed in imported modules. I will add that, too, thanks!

Cool.

What is the latest syntax you are using? Did you consider any of the lighter weight options? That subthread died without conclusion (unless I missed something somehow).

- Anton

2016-05-21 0:01 GMT+03:00 Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>>:

On May 20, 2016, at 3:51 PM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On May 20, 2016, at 1:25 PM, Антон Жилин <antonyzhilin@gmail.com <mailto:antonyzhilin@gmail.com>> wrote:
Inline:

2016-05-20 20:58 GMT+03:00 John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>>:
The transitivity rule plus the ability to define precedence relationships in both directions on a new precedence group allows a new precedence group to create a precedence relationship between existing unrelated precedence groups. This should be forbidden.

Agreed, although there is an alternate solution to allow global-scope relationship definition.
Trying to write it formally:

====begin====
Precedence relationships that, by transitivity rule, create relationship between two imported groups, is an error. Example:

// Module X
precedencegroup A { }
precedencegroup C { }

// Module Y
import X
precedencegroup B { precedence(> A) precedence(< C) }

This results in compilation error "B uses transitivity to define relationship between imported groups A and C".
The rationale behind this is that otherwise one can create relationships between standard precedence groups that are confusing for the reader.
====end====

Seems good to me.

Would this be allowed if Module X already defined precedence group C > A (it would not be defining a *new* relationship between A and C in that case)?

What's the purpose of equality relationships between precedence groups?

Agreed, will remove.

Ok.

Your proposal should call out the special treatment of the Assignment and Ternary groups.

Do you mean that most operators should define greater precedence than Assignment / Ternary? Or there should be some other special treatment?

Just that they have implicit members.

John.

19

My working version is still the one in the proposal, but I'm planning to add the alternative versions we discussed, including your and Brent's variants.

IMHO, original version is heavy, but clear (not to confuse with "clean"). Your lighter version looks more clean, but somewhat less consistent and more free in terms of grammar.

Also, I've got another version, which is considerably ligher than current one, while being as structured:

precedence Multiplicative {
    associativity(left)
    above(Additive)
    below(Exponentiative)
}

Why not:

precedence Multiplicative {
    associativity left
    above Additive
    below Epxonentiative
}

Just seeing if removing the parens reduces some of the noise.

I would be happy with this. It is almost the same as what I had suggested, just using > and < rather than above and below (because that was what the proposal was using). Using words instead is fine with me. The parens are my biggest objection in this version. In the original version I also didn’t like the verbosity of `precedencegroup` and the redundant statement `precedence` inside the braces.

···

On May 20, 2016, at 5:06 PM, Brandon Knope <bknope@me.com> wrote:
On May 20, 2016, at 5:56 PM, Антон Жилин via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Sorry if I missed this suggestion earlier and it was denied :P

Brandon

- Anton

2016-05-21 0:25 GMT+03:00 Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>>:

On May 20, 2016, at 4:22 PM, Антон Жилин <antonyzhilin@gmail.com <mailto:antonyzhilin@gmail.com>> wrote:

Yes, in this case it should be allowed, because this relationship already existed in imported modules. I will add that, too, thanks!

Cool.

What is the latest syntax you are using? Did you consider any of the lighter weight options? That subthread died without conclusion (unless I missed something somehow).

- Anton

2016-05-21 0:01 GMT+03:00 Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>>:

On May 20, 2016, at 3:51 PM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On May 20, 2016, at 1:25 PM, Антон Жилин <antonyzhilin@gmail.com <mailto:antonyzhilin@gmail.com>> wrote:
Inline:

2016-05-20 20:58 GMT+03:00 John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>>:
The transitivity rule plus the ability to define precedence relationships in both directions on a new precedence group allows a new precedence group to create a precedence relationship between existing unrelated precedence groups. This should be forbidden.

Agreed, although there is an alternate solution to allow global-scope relationship definition.
Trying to write it formally:

====begin====
Precedence relationships that, by transitivity rule, create relationship between two imported groups, is an error. Example:

// Module X
precedencegroup A { }
precedencegroup C { }

// Module Y
import X
precedencegroup B { precedence(> A) precedence(< C) }

This results in compilation error "B uses transitivity to define relationship between imported groups A and C".
The rationale behind this is that otherwise one can create relationships between standard precedence groups that are confusing for the reader.
====end====

Seems good to me.

Would this be allowed if Module X already defined precedence group C > A (it would not be defining a *new* relationship between A and C in that case)?

What's the purpose of equality relationships between precedence groups?

Agreed, will remove.

Ok.

Your proposal should call out the special treatment of the Assignment and Ternary groups.

Do you mean that most operators should define greater precedence than Assignment / Ternary? Or there should be some other special treatment?

Just that they have implicit members.

John.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

20

My working version is still the one in the proposal, but I'm planning to add the alternative versions we discussed, including your and Brent's variants.

IMHO, original version is heavy, but clear (not to confuse with "clean"). Your lighter version looks more clean, but somewhat less consistent and more free in terms of grammar.

Also, I've got another version, which is considerably ligher than current one, while being as structured:

precedence Multiplicative {
    associativity(left)
    above(Additive)
    below(Exponentiative)
}

Why not:

precedence Multiplicative {
    associativity left
    above Additive
    below Epxonentiative
}

Just seeing if removing the parens reduces some of the noise.

Sorry if I missed this suggestion earlier and it was denied :P

Brandon

···

On May 20, 2016, at 5:56 PM, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:

- Anton

2016-05-21 0:25 GMT+03:00 Matthew Johnson <matthew@anandabits.com>:

On May 20, 2016, at 4:22 PM, Антон Жилин <antonyzhilin@gmail.com> wrote:

Yes, in this case it should be allowed, because this relationship already existed in imported modules. I will add that, too, thanks!

Cool.

What is the latest syntax you are using? Did you consider any of the lighter weight options? That subthread died without conclusion (unless I missed something somehow).

- Anton

2016-05-21 0:01 GMT+03:00 Matthew Johnson <matthew@anandabits.com>:

On May 20, 2016, at 3:51 PM, John McCall <rjmccall@apple.com> wrote:

On May 20, 2016, at 1:25 PM, Антон Жилин <antonyzhilin@gmail.com> wrote:
Inline:

2016-05-20 20:58 GMT+03:00 John McCall <rjmccall@apple.com>:

The transitivity rule plus the ability to define precedence relationships in both directions on a new precedence group allows a new precedence group to create a precedence relationship between existing unrelated precedence groups. This should be forbidden.

Agreed, although there is an alternate solution to allow global-scope relationship definition.
Trying to write it formally:

====begin====
Precedence relationships that, by transitivity rule, create relationship between two imported groups, is an error. Example:

// Module X
precedencegroup A { }
precedencegroup C { }

// Module Y
import X
precedencegroup B { precedence(> A) precedence(< C) }

This results in compilation error "B uses transitivity to define relationship between imported groups A and C".
The rationale behind this is that otherwise one can create relationships between standard precedence groups that are confusing for the reader.
====end====

Seems good to me.

Would this be allowed if Module X already defined precedence group C > A (it would not be defining a *new* relationship between A and C in that case)?

What's the purpose of equality relationships between precedence groups?

Agreed, will remove.

Ok.

Your proposal should call out the special treatment of the Assignment and Ternary groups.

Do you mean that most operators should define greater precedence than Assignment / Ternary? Or there should be some other special treatment?

Just that they have implicit members.

John.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution