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

I replaced `precedencegroup` with `precedence` and added `Precedence`
suffix to all precedence group names. See:

https://github.com/Anton3/swift-evolution/blob/fix-operator-
precedence/proposals/0077-operator-precedence.md

My feelings:
1. `precedencegroup` describes what it declares more precisely
2. `precedence` is shorter (partially compensating for longer names)
3. `precedence` can be correctly interpreted as "precedence level"
4. `precedence` looks nicer overall

5. `Precedence` suffix is bulky. One must specify it in operator
declarations and in all relationships
6. All groups ending with adjectives may unambiguously drop the suffix
7. Number of such groups is small. New groups will tend to be named after
corresponding operators, and they will be noun-based

Questions:
1. Where else can we drop -Precedence?
2. Can we make more names end with adjectives?

Swift is all about values and protocols, so I was thinking about smthg like this:

enum OperatorAssociativity { case left, right }
enum PrecedenceGroup {
    casedefaultGroup(OperatorAssociativity)
    indirect case strongerThan(OperatorAssociativity,PrecedenceGroup)
    indirect case weakerThan(OperatorAssociativity,PrecedenceGroup)
    indirect case between(OperatorAssociativity, strongerThan: PrecedenceGroup, weakerThan: PrecedenceGroup)
}

let Additive: PrecedenceGroup = .defaultGroup(.left)
let Multiplicative: PrecedenceGroup = .strongerThan(.left, Additive)
let Exponentiative: PrecedenceGroup = .strongerThan(.left, Multiplicative)
let SomeOtherGroup: PrecedenceGroup = .between(.right, strongerThan: Multiplicative, weakerThan: Exponentiative)

standard Swift, which makes it easier to reflect when the api gets created in 4.0

Regards
LM
(From mobile)

···

On Jun 24, 2016, at 2:47 PM, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote:

L. Mihalkovic via swift-evolution <swift-evolution@...> writes:

Could you please explain what you mean by "meta-circular syntax for

the

precedence group definitions"? An example?

=define it using existing swift constructs rather than by extending

swift with new kwd looks like grp

matches a struct.

I still don't fully understand without an example :(
If you mean something like this:

protocol PrecedenceGroup_Additive {
   associatedtype StrongerThan_Comparative
   associatedtype WeakerThan_Multiplicative
}

Then this is just ugly.

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

Don't you think that for no other reason than completeness it would make sense to document the metacircular definition I suggested?

···

On Jun 25, 2016, at 7:57 PM, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote:

I replaced `precedencegroup` with `precedence` and added `Precedence`
suffix to all precedence group names. See:

https://github.com/Anton3/swift-evolution/blob/fix-operator-
precedence/proposals/0077-operator-precedence.md

My feelings:
1. `precedencegroup` describes what it declares more precisely
2. `precedence` is shorter (partially compensating for longer names)
3. `precedence` can be correctly interpreted as "precedence level"
4. `precedence` looks nicer overall

5. `Precedence` suffix is bulky. One must specify it in operator
declarations and in all relationships
6. All groups ending with adjectives may unambiguously drop the suffix
7. Number of such groups is small. New groups will tend to be named after
corresponding operators, and they will be noun-based

Questions:
1. Where else can we drop -Precedence?
2. Can we make more names end with adjectives?

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

I replaced `precedencegroup` with `precedence` and added `Precedence`
suffix to all precedence group names. See:

https://github.com/Anton3/swift-evolution/blob/fix-operator-
precedence/proposals/0077-operator-precedence.md

My feelings:
1. `precedencegroup` describes what it declares more precisely
2. `precedence` is shorter (partially compensating for longer names)
3. `precedence` can be correctly interpreted as "precedence level"
4. `precedence` looks nicer overall

Keep in mind that this is a pretty marginal feature. I'm not sure "precedence" is a reasonable enough thing to take as a keyword for it.

John.

···

On Jun 25, 2016, at 10:57 AM, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote:

5. `Precedence` suffix is bulky. One must specify it in operator
declarations and in all relationships
6. All groups ending with adjectives may unambiguously drop the suffix
7. Number of such groups is small. New groups will tend to be named after
corresponding operators, and they will be noun-based

Questions:
1. Where else can we drop -Precedence?
2. Can we make more names end with adjectives?

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

I did not change 'precedencegroup', but still strongly vote for
'precedence', despite counter-arguments.

But there is a problem besides bikeshedding that we need to solve. We have
the following groups:

Assignment
Ternary
Default
LogicalOr
LogicalAnd
Comparative
NilCoalescing
Cast
Range
Additive
Multiplicative
BitwiseShift

How should we rename them to avoid conflicts?
Simply add -Precedence to everything?
Drop -Precedence for Additive, Multiplicative and Comparative?

L. Mihalkovic via swift-evolution <swift-evolution@...> writes:

Don't you think that for no other reason than completeness it would make

sense to document the metacircular

definition I suggested?

Okay, okay, I will.

I'm just concerned that precedencegroup might be confusing at first look.

But like you said, it's not going to be a widely written feature (but it's will be widely used!).

Also, is taking a keyword at the top level really that bad? Precedence could still be used inside classes and methods etc

Brandon

···

On Jun 27, 2016, at 7:01 PM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 25, 2016, at 10:57 AM, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote:
I replaced `precedencegroup` with `precedence` and added `Precedence`
suffix to all precedence group names. See:

https://github.com/Anton3/swift-evolution/blob/fix-operator-
precedence/proposals/0077-operator-precedence.md

My feelings:
1. `precedencegroup` describes what it declares more precisely
2. `precedence` is shorter (partially compensating for longer names)
3. `precedence` can be correctly interpreted as "precedence level"
4. `precedence` looks nicer overall

Keep in mind that this is a pretty marginal feature. I'm not sure "precedence" is a reasonable enough thing to take as a keyword for it.

John.

5. `Precedence` suffix is bulky. One must specify it in operator
declarations and in all relationships
6. All groups ending with adjectives may unambiguously drop the suffix
7. Number of such groups is small. New groups will tend to be named after
corresponding operators, and they will be noun-based

Questions:
1. Where else can we drop -Precedence?
2. Can we make more names end with adjectives?

_______________________________________________
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

Question inline
Regards
LM
(From mobile)

I replaced `precedencegroup` with `precedence` and added `Precedence`
suffix to all precedence group names. See:

https://github.com/Anton3/swift-evolution/blob/fix-operator-
precedence/proposals/0077-operator-precedence.md

My feelings:
1. `precedencegroup` describes what it declares more precisely
2. `precedence` is shorter (partially compensating for longer names)
3. `precedence` can be correctly interpreted as "precedence level"
4. `precedence` looks nicer overall

Keep in mind that this is a pretty marginal feature. I'm not sure "precedence" is a reasonable enough thing to take as a keyword for it.

John.

Would a meta-circular definition be possible (proposed a version using enums)? I remember a mail from chris about moving certain things currently backed into the compiler towards the stdlib, is this one a possible candidate...

···

On Jun 28, 2016, at 1:01 AM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 25, 2016, at 10:57 AM, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote:

5. `Precedence` suffix is bulky. One must specify it in operator
declarations and in all relationships
6. All groups ending with adjectives may unambiguously drop the suffix
7. Number of such groups is small. New groups will tend to be named after
corresponding operators, and they will be noun-based

Questions:
1. Where else can we drop -Precedence?
2. Can we make more names end with adjectives?

_______________________________________________
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

This is already strongly library-determined. The library defines what operators exist and defines their precedence w.r.t. each other and a small number of built-in operators. Operator precedence has to be communicated to the compiler somehow in order to parse code. This proposal is just deciding the syntax of that communication.

I see no reason to use a more conceptually complex approach when a simple declaration will do.

John.

···

On Jun 28, 2016, at 9:12 AM, L. Mihalkovic <laurent.mihalkovic@gmail.com> wrote:

Question inline
Regards
LM
(From mobile)
On Jun 28, 2016, at 1:01 AM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 25, 2016, at 10:57 AM, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote:
I replaced `precedencegroup` with `precedence` and added `Precedence`
suffix to all precedence group names. See:

https://github.com/Anton3/swift-evolution/blob/fix-operator-
precedence/proposals/0077-operator-precedence.md

My feelings:
1. `precedencegroup` describes what it declares more precisely
2. `precedence` is shorter (partially compensating for longer names)
3. `precedence` can be correctly interpreted as "precedence level"
4. `precedence` looks nicer overall

Keep in mind that this is a pretty marginal feature. I'm not sure "precedence" is a reasonable enough thing to take as a keyword for it.

John.

Would a meta-circular definition be possible (proposed a version using enums)? I remember a mail from chris about moving certain things currently backed into the compiler towards the stdlib, is this one a possible candidate...

Regards
LM
(From mobile)

···

On Jun 28, 2016, at 6:32 PM, John McCall <rjmccall@apple.com> wrote:

On Jun 28, 2016, at 9:12 AM, L. Mihalkovic <laurent.mihalkovic@gmail.com> wrote:

Question inline
Regards
LM
(From mobile)
On Jun 28, 2016, at 1:01 AM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 25, 2016, at 10:57 AM, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote:
I replaced `precedencegroup` with `precedence` and added `Precedence`
suffix to all precedence group names. See:

https://github.com/Anton3/swift-evolution/blob/fix-operator-
precedence/proposals/0077-operator-precedence.md

My feelings:
1. `precedencegroup` describes what it declares more precisely
2. `precedence` is shorter (partially compensating for longer names)
3. `precedence` can be correctly interpreted as "precedence level"
4. `precedence` looks nicer overall

Keep in mind that this is a pretty marginal feature. I'm not sure "precedence" is a reasonable enough thing to take as a keyword for it.

John.

Would a meta-circular definition be possible (proposed a version using enums)? I remember a mail from chris about moving certain things currently backed into the compiler towards the stdlib, is this one a possible candidate...

This is already strongly library-determined. The library defines what operators exist and defines their precedence w.r.t. each other and a small number of built-in operators. Operator precedence has to be communicated to the compiler somehow in order to parse code. This proposal is just deciding the syntax of that communication.

I see no reason to use a more conceptually complex approach when a simple declaration will do.

Np... I thought that enums instead of keywords would also make them naturally discoverable when a reflection API gets created. Felt odd to see so many new language keywd assigned to a single feature.