[Review] SE-0077 v2: Improved operator declarations

Evolution Announcements
1

Hello Swift community,

The second review of “Improved operator declarations” begins now and runs through July 4, 2016. The proposal is available here:

The previous version of the proposal that was reviewed can be seen here:

with review discussion archived in this thread:

  [swift-evolution] [Review] SE-0077: Improved operator declarations
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. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

Reply text

Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine 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,

-Joe

2

What is your evaluation of the proposal?

+1 in general. However, I really don’t like the names `strongerThan` and `weakerThan`. As I mentioned in the discussion, we usually speak of “higher” and “lower” precedence. IMO this implies that the appropriate names are “higherThan” and “lowerThan”, or if we prefer more concise single words, “above” and “below” (the latter is my personal preference).

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

Yes. Precedence values are a pragmatic but inelegant decision. I will be glad to see them go.

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

Yes, very much.

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

This proposal will provide Swift with the most sophisticated operator mechanism of any language I am familiar with. I do not know of anything quite like it.

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

In depth study and participation in both discussions as well as the prior review.

···

More information about the Swift evolution process is available at

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

-Joe

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

3

/0077-operator-precedence.md

Idea #1

There is a high chance that 'higherThan'/'lowerThan' names will be
chosen. I still see a problem with that. Keywords in Swift are written
in full lowercase, so we should actually take 'higherthan'/'lowerthan'.

But then what's the point of the preposition? It blends with
higher/lower and doesn't actually add any clarity. So we should drop
'than' and have just higher/lower or above/below or succeeds/preceeds or
whatever we choose, but *in a single word*.

Idea #2

I personally don't like the direction in which the proposal moved (I
understand the reasons). Before the first review, consensus seemed to be
on this:

precedence Multiplicative {
    above Additive
    below Exponentiative
}

And now:

precedencegroup MultiplicativePrecedence {
    higherThan: AdditivePrecedence
    lowerThan: ExponentiativePrecedence
}

Don't you have a feeling that something cute and 'swift' was turned into
a monster?

At least, if we change keywords, we will get this:

precedence MultiplicativePrecedence {
    above: AdditivePrecedence
    below: ExponentiativePrecedence
}

I also like in above/below that they are written with the same number of
letters, meaning that they will line up nicely.

4

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

Alternatives:

  precedencegroup MultiplicativePrecedence : left where Self > AdditivePrecedence

  precedencegroup MultiplicativePrecedence {
      Self > AdditivePrecedence
      associativity : left
  }

-- Ben

5

Proposal link:

Dave, Max and I discussed SE-0077 and reviewed the names of precedence
groups.
Here's our recommendation.

In general, we think some names don't read well and have some ambiguities,
for
example, "LogicalAndPrecedence" (looks like a conjunction),
"AdditivePrecedence" ("additive" is an adjective that modifies
"precedence"),
"RangePrecedence" ("range" is not an adjective, stands out).

We think that two directions would be fruitful:

1. If the names of precedence groups will be in the same namespace as
types,
    then we recommend pushing the names of precedence groups into a
"namespace",
    for example "Precedence.Assignment".

2. If (1) is not workable, we suggest incrementally improving existing
names
    to make them more readable and less ambiguous. We think that making the
    names less technical by naming the groups after a representative
operation
    will be easier for users to understand (instead of "AdditivePrecence" we
    are proposing "AdditionPrecedence"). We also think that using an
adjective
    before "Precedence" does not read well in many cases
    ("NilCoalescingPrecedence": precedence that coalesces nils).

Current name | Namespacing | Incremental
improvement
------------------------|-----------------------------|-----------------------------
AssignmentPrecedence | Precedence.Assignment | no change
TernaryPrecedence | Precedence.Ternary | no change
DefaultPrecedence | Precedence.Default | no change
LogicalOrPrecedence | Precedence.LogicalOr |
DisjunctionPrecedence
LogicalAndPrecedence | Precedence.LogicalAnd |
ConjunctionPrecedence
ComparativePrecedence | Precedence.Comparison | ComparisonPrecedence
NilCoalescingPrecedence | Precedence.NilCoalescing | no change
CastPrecedence | Precedence.Casting | no change
RangePrecedence | Precedence.RangeForming |
RangeFormationPrecedence
AdditivePrecedence | Precedence.Addition | AdditionPrecedence
MultiplicativePrecedence> Precedence.Multiplication |
MultiplicationPrecedence
BitwiseShiftPrecedence | Precedence.BitwiseShift |
BitwiseShiftPrecedence

Dmitri

···

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

6

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

Idea #1

There is a high chance that 'higherThan'/'lowerThan' names will be
chosen.

What is giving you this idea? Did I miss some part of the conversation? I don't recall any indication of what the final keywords will be.

I still see a problem with that. Keywords in Swift are written
in full lowercase, so we should actually take 'higherthan'/'lowerthan'.

But then what's the point of the preposition? It blends with
higher/lower and doesn't actually add any clarity. So we should drop
'than' and have just higher/lower or above/below or succeeds/preceeds or
whatever we choose, but *in a single word*.

Idea #2

I personally don't like the direction in which the proposal moved (I
understand the reasons). Before the first review, consensus seemed to be
on this:

precedence Multiplicative {
   above Additive
   below Exponentiative
}

And now:

precedencegroup MultiplicativePrecedence {
   higherThan: AdditivePrecedence
   lowerThan: ExponentiativePrecedence
}

I'm really not sure why you think there is any kind of consensus on this. I must have missed something.

Don't you have a feeling that something cute and 'swift' was turned into
a monster?

At least, if we change keywords, we will get this:

precedence MultiplicativePrecedence {
   above: AdditivePrecedence
   below: ExponentiativePrecedence
}

I also like in above/below that they are written with the same number of
letters, meaning that they will line up nicely.

I agree. As stated in my review, this is my preference.

···

Sent from my iPad

On Jun 30, 2016, at 4:34 AM, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote:

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

7

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

Idea #1

There is a high chance that 'higherThan'/'lowerThan' names will be
chosen. I still see a problem with that. Keywords in Swift are written
in full lowercase, so we should actually take 'higherthan'/'lowerthan'.

But then what's the point of the preposition? It blends with
higher/lower and doesn't actually add any clarity. So we should drop
'than' and have just higher/lower or above/below or succeeds/preceeds or
whatever we choose, but *in a single word*.

These aren't formal keywords, though, they're contextual to a precedence group declaration.

Idea #2

I personally don't like the direction in which the proposal moved (I
understand the reasons). Before the first review, consensus seemed to be
on this:

precedence Multiplicative {
   above Additive
   below Exponentiative
}

And now:

precedencegroup MultiplicativePrecedence {
   higherThan: AdditivePrecedence
   lowerThan: ExponentiativePrecedence
}

Don't you have a feeling that something cute and 'swift' was turned into
a monster?

At least, if we change keywords, we will get this:

precedence MultiplicativePrecedence {
   above: AdditivePrecedence
   below: ExponentiativePrecedence
}

I also like in above/below that they are written with the same number of
letters, meaning that they will line up nicely.

To reiterate the core team's rationale, precedence groups ought to be a relatively rare thing. Few users ought to be defining new operators, fewer still new precedence groups. Furthermore, the '-Precedence' word clarifies the use site in an operator decl:

  infix operator ¶ : PilcrowPrecedence

making it clear that the ':' is associating a precedence with the operator. Since operator decls are themselves hopefully rare as well, this added clarity should hopefully save unfamiliar users a trip to Stack Overflow.

-Joe

···

On Jun 30, 2016, at 2:34 AM, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote:

8

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

Idea #1

There is a high chance that 'higherThan'/'lowerThan' names will be
chosen. I still see a problem with that. Keywords in Swift are written
in full lowercase, so we should actually take 'higherthan'/'lowerthan'.

But then what's the point of the preposition? It blends with
higher/lower and doesn't actually add any clarity. So we should drop
'than' and have just higher/lower or above/below or succeeds/preceeds or
whatever we choose, but *in a single word*.

The preposition does add clarity. Are the listed precedences the ones that are
higher than the current precedence, or are they the ones that the current
precedence is higher than?

John.

···

On Jun 30, 2016, at 2:34 AM, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote:

Idea #2

I personally don't like the direction in which the proposal moved (I
understand the reasons). Before the first review, consensus seemed to be
on this:

precedence Multiplicative {
   above Additive
   below Exponentiative
}

And now:

precedencegroup MultiplicativePrecedence {
   higherThan: AdditivePrecedence
   lowerThan: ExponentiativePrecedence
}

Don't you have a feeling that something cute and 'swift' was turned into
a monster?

At least, if we change keywords, we will get this:

precedence MultiplicativePrecedence {
   above: AdditivePrecedence
   below: ExponentiativePrecedence
}

I also like in above/below that they are written with the same number of
letters, meaning that they will line up nicely.

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

9

Matthew Johnson via swift-evolution <swift-evolution@...> writes:

> There is a high chance that 'higherThan'/'lowerThan' names will be
> chosen.

What is giving you this idea? Did I miss some part of the

conversation? I don't recall any indication of what

the final keywords will be.

Yesterday Dave Abrahams noted that he was the one who insisted on
'strongerThan'/'weakerThan' and that now he prefers
'higherThan'/'lowerThan'.

> Before the first review, consensus seemed to be
> on this:
>
> precedence Multiplicative {
> above Additive
> below Exponentiative
> }
>
> And now:
>
> precedencegroup MultiplicativePrecedence {
> higherThan: AdditivePrecedence
> lowerThan: ExponentiativePrecedence
> }
>

I'm really not sure why you think there is any kind of consensus on

this. I must have missed something.

At least Xiaodi Wu and Brandon Knope seemed to agree with the first
version. I agree that that alone can't be considered 'consensus'.
Anyway, the point here is that we ended up with a syntax that is bulkier
than it could be.

10

Joe Groff via swift-evolution <swift-evolution@...> writes:

To reiterate the core team's rationale, precedence groups ought to be a

relatively rare thing. Few users

ought to be defining new operators, fewer still new precedence groups.

Furthermore, the '-Precedence'

word clarifies the use site in an operator decl:

  infix operator ¶ : PilcrowPrecedence

making it clear that the ':' is associating a precedence with the

operator. Since operator decls are

themselves hopefully rare as well, this added clarity should hopefully

save unfamiliar users a trip to

Stack Overflow.

Nice explanation, I start to agree that these suffixes are not just
necessary evil, but something that can really help.

I also don't know where to put it, so I will here.
I understand reasons for not taking 'precedence' keyword, but still very
much like this variant. Together with -Precedence suffix, it can form
complete analogy with protocols.

I find the argument that precedence groups are less significant that
protocols not convincing enough. In APIs, we will still be able to use it,
as we can use 'protocol' and 'default' after dot without escaping.

11

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

Dave, Max and I discussed SE-0077 and reviewed the names of precedence groups.
Here's our recommendation.

In general, we think some names don't read well and have some ambiguities, for
example, "LogicalAndPrecedence" (looks like a conjunction),
"AdditivePrecedence" ("additive" is an adjective that modifies "precedence"),
"RangePrecedence" ("range" is not an adjective, stands out).

We think that two directions would be fruitful:

1. If the names of precedence groups will be in the same namespace as types,
    then we recommend pushing the names of precedence groups into a "namespace",
    for example "Precedence.Assignment".

We don't have any language features that would allow this.

John.

···

On Jul 7, 2016, at 9:23 AM, Dmitri Gribenko via swift-evolution <swift-evolution@swift.org> wrote:

2. If (1) is not workable, we suggest incrementally improving existing names
    to make them more readable and less ambiguous. We think that making the
    names less technical by naming the groups after a representative operation
    will be easier for users to understand (instead of "AdditivePrecence" we
    are proposing "AdditionPrecedence"). We also think that using an adjective
    before "Precedence" does not read well in many cases
    ("NilCoalescingPrecedence": precedence that coalesces nils).

Current name | Namespacing | Incremental improvement
------------------------|-----------------------------|-----------------------------
AssignmentPrecedence | Precedence.Assignment | no change
TernaryPrecedence | Precedence.Ternary | no change
DefaultPrecedence | Precedence.Default | no change
LogicalOrPrecedence | Precedence.LogicalOr | DisjunctionPrecedence
LogicalAndPrecedence | Precedence.LogicalAnd | ConjunctionPrecedence
ComparativePrecedence | Precedence.Comparison | ComparisonPrecedence
NilCoalescingPrecedence | Precedence.NilCoalescing | no change
CastPrecedence | Precedence.Casting | no change
RangePrecedence | Precedence.RangeForming | RangeFormationPrecedence
AdditivePrecedence | Precedence.Addition | AdditionPrecedence
MultiplicativePrecedence> Precedence.Multiplication | MultiplicationPrecedence
BitwiseShiftPrecedence | Precedence.BitwiseShift | BitwiseShiftPrecedence

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com <mailto:gribozavr@gmail.com>>*/
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

12

Matthew Johnson via swift-evolution <swift-evolution@...> writes:

There is a high chance that 'higherThan'/'lowerThan' names will be
chosen.

What is giving you this idea? Did I miss some part of the

conversation? I don't recall any indication of what

the final keywords will be.

Yesterday Dave Abrahams noted that he was the one who insisted on
'strongerThan'/'weakerThan' and that now he prefers
'higherThan'/'lowerThan’.

Are you talking about this post? [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

I didn’t interpret that as endorsing any particular keywords, just as an acknowledgement that “stronger/weaker” is not the usual terminology and that “higher/lower” is.

Before the first review, consensus seemed to be
on this:

precedence Multiplicative {
  above Additive
  below Exponentiative
}

And now:

precedencegroup MultiplicativePrecedence {
  higherThan: AdditivePrecedence
  lowerThan: ExponentiativePrecedence
}

I'm really not sure why you think there is any kind of consensus on

this. I must have missed something.

At least Xiaodi Wu and Brandon Knope seemed to agree with the first
version. I agree that that alone can't be considered 'consensus'.
Anyway, the point here is that we ended up with a syntax that is bulkier
than it could be.

Agree. I hope we will avoid that.

···

On Jun 30, 2016, at 7:58 AM, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote:

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

13

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

Idea #1

There is a high chance that 'higherThan'/'lowerThan' names will be
chosen. I still see a problem with that. Keywords in Swift are written
in full lowercase, so we should actually take 'higherthan'/'lowerthan'.

But then what's the point of the preposition? It blends with
higher/lower and doesn't actually add any clarity. So we should drop
'than' and have just higher/lower or above/below or succeeds/preceeds or
whatever we choose, but *in a single word*.

The preposition does add clarity. Are the listed precedences the ones that are
higher than the current precedence, or are they the ones that the current
precedence is higher than?

I agree with that for higher and lower, but I think above and below are pretty clear (in the example just below it seems very clear (to me at least) that Multiplicative is above additive and below Exponentiative).

I think above and below are aesthetically the best here, but as has been noted this will be a rarely used feature so I won't feel bad if something else is selected,

···

Sent from my iPad
On Jun 30, 2016, at 1:08 PM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 30, 2016, at 2:34 AM, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote:

John.

Idea #2

I personally don't like the direction in which the proposal moved (I
understand the reasons). Before the first review, consensus seemed to be
on this:

precedence Multiplicative {
  above Additive
  below Exponentiative
}

And now:

precedencegroup MultiplicativePrecedence {
  higherThan: AdditivePrecedence
  lowerThan: ExponentiativePrecedence
}

Don't you have a feeling that something cute and 'swift' was turned into
a monster?

At least, if we change keywords, we will get this:

precedence MultiplicativePrecedence {
  above: AdditivePrecedence
  below: ExponentiativePrecedence
}

I also like in above/below that they are written with the same number of
letters, meaning that they will line up nicely.

_______________________________________________
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

14

John McCall via swift-evolution <swift-evolution@...> writes:

> There is a high chance that 'higherThan'/'lowerThan' names will be
> chosen. I still see a problem with that. Keywords in Swift are

written

> in full lowercase, so we should actually take

'higherthan'/'lowerthan'.

>
> But then what's the point of the preposition? It blends with
> higher/lower and doesn't actually add any clarity. So we should drop
> 'than' and have just higher/lower or above/below or

succeeds/preceeds or

> whatever we choose, but *in a single word*.

The preposition does add clarity. Are the listed precedences the ones

that are

higher than the current precedence, or are they the ones that the

current

precedence is higher than?

John.

I meant that following keywords should be preferred to be written in all
lowercase. But in our case, we lose clarity from doing so.

An elegant solution seems to be to find expressive single-word keywords
for our purpose, their advantage is that they can strictly follow
keyword naming rules without losing clarity.

It seems that mine and some other people' concerns are based on this
naming inconsistency of higherThan and lowerThan. There are plenty of
other good options: above/below, before/after, precedes/succeeds.

I know your opinion, but anyways want this argument to be risen during
internal discussion.

15

'precedencegroup' that is being proposed is a new language feature, we
can choose to use any syntax we like with it.

Dmitri

···

On Thu, Jul 7, 2016 at 9:27 AM, John McCall <rjmccall@apple.com> wrote:

On Jul 7, 2016, at 9:23 AM, Dmitri Gribenko via swift-evolution > <swift-evolution@swift.org> wrote:

Proposal link:

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

Dave, Max and I discussed SE-0077 and reviewed the names of precedence
groups.
Here's our recommendation.

In general, we think some names don't read well and have some ambiguities,
for
example, "LogicalAndPrecedence" (looks like a conjunction),
"AdditivePrecedence" ("additive" is an adjective that modifies
"precedence"),
"RangePrecedence" ("range" is not an adjective, stands out).

We think that two directions would be fruitful:

1. If the names of precedence groups will be in the same namespace as
types,
    then we recommend pushing the names of precedence groups into a
"namespace",
    for example "Precedence.Assignment".

We don't have any language features that would allow this.

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

16

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

Idea #1

There is a high chance that 'higherThan'/'lowerThan' names will be
chosen. I still see a problem with that. Keywords in Swift are written
in full lowercase, so we should actually take 'higherthan'/'lowerthan'.

But then what's the point of the preposition? It blends with
higher/lower and doesn't actually add any clarity. So we should drop
'than' and have just higher/lower or above/below or succeeds/preceeds or
whatever we choose, but *in a single word*.

The preposition does add clarity. Are the listed precedences the ones that are
higher than the current precedence, or are they the ones that the current
precedence is higher than?

I agree with that for higher and lower, but I think above and below are pretty clear (in the example just below it seems very clear (to me at least) that Multiplicative is above additive and below Exponentiative).

I think above and below are aesthetically the best here, but as has been noted this will be a rarely used feature so I won't feel bad if something else is selected,

I would be fine with "above" and "below".

John.

···

On Jun 30, 2016, at 11:25 AM, Matthew Johnson <matthew@anandabits.com> wrote:
On Jun 30, 2016, at 1:08 PM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 30, 2016, at 2:34 AM, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote:

John.

Idea #2

I personally don't like the direction in which the proposal moved (I
understand the reasons). Before the first review, consensus seemed to be
on this:

precedence Multiplicative {
above Additive
below Exponentiative
}

And now:

precedencegroup MultiplicativePrecedence {
higherThan: AdditivePrecedence
lowerThan: ExponentiativePrecedence
}

Don't you have a feeling that something cute and 'swift' was turned into
a monster?

At least, if we change keywords, we will get this:

precedence MultiplicativePrecedence {
above: AdditivePrecedence
below: ExponentiativePrecedence
}

I also like in above/below that they are written with the same number of
letters, meaning that they will line up nicely.

_______________________________________________
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

17

As Anton mentioned earlier, I feel the same way with respect to naming. No
need to reiterate the points already made, but I do want to chime in on the
topic of rarely used syntax.

While I agree of course that a cumbersome syntax for a rarely used feature
is _not as bad_ as a cumbersome syntax for a common feature, all other
things being equal, I think we should press for the most elegant possible
syntax for all aspects of the language. It is needless, IMO, to insist that
less commonly used features *ought* to be weighed down with more cumbersome
spelling.

···

On Thu, Jun 30, 2016 at 13:25 Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote:

Sent from my iPad

On Jun 30, 2016, at 1:08 PM, John McCall via swift-evolution < > swift-evolution@swift.org> wrote:

>> On Jun 30, 2016, at 2:34 AM, Anton Zhilin via swift-evolution < > swift-evolution@swift.org> wrote:
>> https://github.com/apple/swift-evolution/blob/master/proposals
>> /0077-operator-precedence.md
>>
>> Idea #1
>>
>> There is a high chance that 'higherThan'/'lowerThan' names will be
>> chosen. I still see a problem with that. Keywords in Swift are written
>> in full lowercase, so we should actually take 'higherthan'/'lowerthan'.
>>
>> But then what's the point of the preposition? It blends with
>> higher/lower and doesn't actually add any clarity. So we should drop
>> 'than' and have just higher/lower or above/below or succeeds/preceeds or
>> whatever we choose, but *in a single word*.
>
> The preposition does add clarity. Are the listed precedences the ones
that are
> higher than the current precedence, or are they the ones that the current
> precedence is higher than?

I agree with that for higher and lower, but I think above and below are
pretty clear (in the example just below it seems very clear (to me at
least) that Multiplicative is above additive and below Exponentiative).

I think above and below are aesthetically the best here, but as has been
noted this will be a rarely used feature so I won't feel bad if something
else is selected,

>
> John.
>
>>
>> Idea #2
>>
>> I personally don't like the direction in which the proposal moved (I
>> understand the reasons). Before the first review, consensus seemed to be
>> on this:
>>
>> precedence Multiplicative {
>> above Additive
>> below Exponentiative
>> }
>>
>> And now:
>>
>> precedencegroup MultiplicativePrecedence {
>> higherThan: AdditivePrecedence
>> lowerThan: ExponentiativePrecedence
>> }
>>
>> Don't you have a feeling that something cute and 'swift' was turned into
>> a monster?
>>
>> At least, if we change keywords, we will get this:
>>
>> precedence MultiplicativePrecedence {
>> above: AdditivePrecedence
>> below: ExponentiativePrecedence
>> }
>>
>> I also like in above/below that they are written with the same number of
>> letters, meaning that they will line up nicely.
>>
>> _______________________________________________
>> 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

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

18

On painting the relative-precedence bikeshed, I would lean slightly toward
“before” and “after”. They are short, single words with unambiguous meaning.

Moreover, the actual point of interest is “Which operators will be
evaluated before which other ones?”

Plus the word “precedence” itself connotes the idea of one thing preceding
another, which is exactly what “before” and “after” convey.

It is true that we often talk about things having “higher” precedence, but
in context that becomes “higherThan”, which is lengthy.

Now “above” / “below” would work just fine, though to me at least it isn’t
as immediately-self-evident which is which for operators, as it would be
with “before” / “after”.

Another option would be “aheadOf” / “behind”, which seem clear in meaning
but mismatched in word-count.

Actually, I think “precedes” / “follows” might be worth considering. The
former would be more common and it exactly matches not only the semantic
but the exact terminology we want. Maybe “follows” isn’t maximally ideal,
but at least it doesn’t have a synonym problem like “succeeds” does.

Even there though, an ambiguity exists between “the group being
defined precedes the listed one” and “the listed group precedes the one
being defined”.

So I would still tend toward prepositional descriptors, especially “before”
and “after”.

Nevin

···

On Friday, July 1, 2016, Anton Zhilin via swift-evolution < swift-evolution@swift.org> wrote:

John McCall via swift-evolution <swift-evolution@...> writes:

> > There is a high chance that 'higherThan'/'lowerThan' names will be
> > chosen. I still see a problem with that. Keywords in Swift are
written
> > in full lowercase, so we should actually take
'higherthan'/'lowerthan'.
> >
> > But then what's the point of the preposition? It blends with
> > higher/lower and doesn't actually add any clarity. So we should drop
> > 'than' and have just higher/lower or above/below or
succeeds/preceeds or
> > whatever we choose, but *in a single word*.
>
> The preposition does add clarity. Are the listed precedences the ones
that are
> higher than the current precedence, or are they the ones that the
current
> precedence is higher than?
>
> John.

I meant that following keywords should be preferred to be written in all
lowercase. But in our case, we lose clarity from doing so.

An elegant solution seems to be to find expressive single-word keywords
for our purpose, their advantage is that they can strictly follow
keyword naming rules without losing clarity.

It seems that mine and some other people' concerns are based on this
naming inconsistency of higherThan and lowerThan. There are plenty of
other good options: above/below, before/after, precedes/succeeds.

I know your opinion, but anyways want this argument to be risen during
internal discussion.

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

19

>> Proposal link:
>>
>>
>>
https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md
>
> Dave, Max and I discussed SE-0077 and reviewed the names of precedence
> groups.
> Here's our recommendation.
>
> In general, we think some names don't read well and have some
ambiguities,
> for
> example, "LogicalAndPrecedence" (looks like a conjunction),
> "AdditivePrecedence" ("additive" is an adjective that modifies
> "precedence"),
> "RangePrecedence" ("range" is not an adjective, stands out).
>
> We think that two directions would be fruitful:
>
> 1. If the names of precedence groups will be in the same namespace as
> types,
> then we recommend pushing the names of precedence groups into a
> "namespace",
> for example "Precedence.Assignment".
>
>
> We don't have any language features that would allow this.

'precedencegroup' that is being proposed is a new language feature, we
can choose to use any syntax we like with it.

If you're going to design a new language feature to sink precedence groups
into a namespace of their own, you might as well sink them into an
unutterable namespace, effectively moving them out of the same namespace as
types altogether, no?

···

On Thu, Jul 7, 2016 at 11:28 AM, Dmitri Gribenko via swift-evolution < swift-evolution@swift.org> wrote:

On Thu, Jul 7, 2016 at 9:27 AM, John McCall <rjmccall@apple.com> wrote:
> On Jul 7, 2016, at 9:23 AM, Dmitri Gribenko via swift-evolution > > <swift-evolution@swift.org> wrote:

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

20

An important thing to consider is if we really want to break standard
library precedence hierarchy.
If we don't, then the proposal loses significance immediately.
If we do, then we should start discussion of specific changes right after
this one.

I'm fine with NilCoalescingPrecedence, because Coalescing is a noun in this
case. For example, we talk about "nil coalescing" operator.

Situation with namespacing is more intricate. I don't mind Precedence
suffixes very much (better make keywords shorter), but it would be great if
we came up with an elegant solution for dropping them.
One idea: add Precedence suffix automatically: 'precedence Additive',
'before: Additive', BUT 'Swift.AdditivePrecedence'.

···

2016-07-07 19:28 GMT+03:00 Dmitri Gribenko via swift-evolution < swift-evolution@swift.org>:

On Thu, Jul 7, 2016 at 9:27 AM, John McCall <rjmccall@apple.com> wrote:
> On Jul 7, 2016, at 9:23 AM, Dmitri Gribenko via swift-evolution > > <swift-evolution@swift.org> wrote:
>> Proposal link:
>>
>>
https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md
>
> Dave, Max and I discussed SE-0077 and reviewed the names of precedence
> groups.
> Here's our recommendation.
>
> In general, we think some names don't read well and have some
ambiguities,
> for
> example, "LogicalAndPrecedence" (looks like a conjunction),
> "AdditivePrecedence" ("additive" is an adjective that modifies
> "precedence"),
> "RangePrecedence" ("range" is not an adjective, stands out).
>
> We think that two directions would be fruitful:
>
> 1. If the names of precedence groups will be in the same namespace as
> types,
> then we recommend pushing the names of precedence groups into a
> "namespace",
> for example "Precedence.Assignment".
>
> We don't have any language features that would allow this.

'precedencegroup' that is being proposed is a new language feature, we
can choose to use any syntax we like with it.