[Proposal] Custom operators

Антон Жилин:

No new suggestions have come in 2 days, and so I have created a pull request!
Operator precedence by Anton3 · Pull Request #253 · apple/swift-evolution · GitHub

1. Assignment operators in Swift 2.2 have an `assignment` keyword:

infix operator += {
  associativity right
  precedence 90
  assignment
}

2. If assignments can't be chained, should they be non-associative?

3. Instead of `precedencegroup`, I suggest an abstract declaration:

operator Multiplicative {
  associativity(left)
  precedence(> Additive)
}
infix operator * : Multiplicative

4. In your proposal, `NilCoalesting` should be `NilCoalescing`.

-- Ben

I'm in favor of declaring precedence relationships inside precedencegroup declarations. So they have a fixed place where they are defined.

The only minor syntax issue I have is that it is not immediately clear which operators belong to a precedence group. The former syntax with the "members(+, -)" solved this issue. However this has (currently) an extensibility problem:
If you define a new operator and it should belong to a precedencegroup where you have no access to its source (like Additive) then the whole argument about having operators in one place.

Another minor issue regarding your implementation of the standard library operators: "Additive" and all "Bitwise" precedencegroups should be above "Range"

// so this is also possible without parentheses
(1+2) ... (3+5)

This issue can be brought up again during another proposal which implements this proposal. So the standard library changes should not belong to this proposal (or least be clarified).

Kind regards
- Maximilian

···

Am 09.04.2016 um 19:43 schrieb Антон Жилин <antonyzhilin@gmail.com>:
[...]
Now, I see only 1 large question/problem risen by David Waite:
Should precedence relationships be defined inside or outside of precedence groups?
That is: should we be able to add arbitrary relationships between existing groups?
[...]

Inline:

[...]

Now, I see only 1 large question/problem risen by David Waite:
Should precedence relationships be defined inside or outside of precedence
groups?
That is: should we be able to add arbitrary relationships between existing
groups?
[...]

I'm in favor of declaring precedence relationships inside precedencegroup
declarations. So they have a fixed place where they are defined.

I'm inclined to agree, but still not completely sure. Maybe someone else
could add a vote? Chris? :)

The only minor syntax issue I have is that it is not immediately clear

which operators belong to a precedence group. The former syntax with the
"members(+, -)" solved this issue. However this has (currently) an
extensibility problem:

If you define a new operator and it should belong to a precedencegroup

where you have no access to its source (like Additive) then the whole
argument about having operators in one place.

My thoughts went as follows.
We should be able to add operators to existing groups, for example, defined
in the Standard Library.
If so, then this this statement should belong to operator, not precedence
group.
But we have to declare the operator anyway, so adding `: Additive` or
something to the declaration does not cause huge code bloat. Especially
considering operators are not defined very often.
Now, we have two ways to do the same thing. External declaration is
necessary and not so bad. So, following a widely known principle, I remove
`members`.

Another minor issue regarding your implementation of the standard library

operators: "Additive" and all "Bitwise" precedencegroups should be above
"Range"

// so this is also possible without parentheses
(1+2) ... (3+5)

This issue can be brought up again during another proposal which
implements this proposal. So the standard library changes *should not*
belong to this proposal (or least be clarified).

Agreed. I will edit that part to form a hierarchy that exactky matches
current state of things.

···

2016-04-10 2:27 GMT+03:00 Maximilian Hünenberger <m.huenenberger@me.com>:

Am 09.04.2016 um 19:43 schrieb Антон Жилин <antonyzhilin@gmail.com>:

Kind regards
- Maximilian

My issue can be solved by the IDE: It could display all operators which are contained in a precedencegroup with quick look or the new interface view in Xcode. However this excludes other IDEs which don't have such features.

But as I said it is only a minor issue.

Best regards
- Maximilian

···

Am 10.04.2016 um 11:48 schrieb Антон Жилин <antonyzhilin@gmail.com>:

2016-04-10 2:27 GMT+03:00 Maximilian Hünenberger <m.huenenberger@me.com>:

[...]

The only minor syntax issue I have is that it is not immediately clear which operators belong to a precedence group. The former syntax with the "members(+, -)" solved this issue. However this has (currently) an extensibility problem:
If you define a new operator and it should belong to a precedencegroup where you have no access to its source (like Additive) then the whole argument about having operators in one place.

My thoughts went as follows.
We should be able to add operators to existing groups, for example, defined in the Standard Library.
If so, then this this statement should belong to operator, not precedence group.
But we have to declare the operator anyway, so adding `: Additive` or something to the declaration does not cause huge code bloat. Especially considering operators are not defined very often.
Now, we have two ways to do the same thing. External declaration is necessary and not so bad. So, following a widely known principle, I remove `members`.

[...]

No new suggestions have come in 2 days, and so I have created a pull
request! Here it is:

If new glitches are suddenly discovered, Core team will still have the
ability to correct them.
So far we have mostly come to consensus.

- Anton

···

2016-04-10 13:18 GMT+03:00 Maximilian Hünenberger <m.huenenberger@me.com>:

Am 10.04.2016 um 11:48 schrieb Антон Жилин <antonyzhilin@gmail.com>:

2016-04-10 2:27 GMT+03:00 Maximilian Hünenberger <m.huenenberger@me.com>:

[...]

The only minor syntax issue I have is that it is not immediately clear

which operators belong to a precedence group. The former syntax with the
"members(+, -)" solved this issue. However this has (currently) an
extensibility problem:

If you define a new operator and it should belong to a precedencegroup

where you have no access to its source (like Additive) then the whole
argument about having operators in one place.

My thoughts went as follows.
We should be able to add operators to existing groups, for example,
defined in the Standard Library.
If so, then this this statement should belong to operator, not precedence
group.
But we have to declare the operator anyway, so adding `: Additive` or
something to the declaration does not cause huge code bloat. Especially
considering operators are not defined very often.
Now, we have two ways to do the same thing. External declaration is
necessary and not so bad. So, following a widely known principle, I remove
`members`.

[...]

My issue can be solved by the IDE: It could display all operators which
are contained in a precedencegroup with quick look or the new interface
view in Xcode. However this excludes other IDEs which don't have such
features.

But as I said it is only a minor issue.

Best regards
- Maximilian

Just want to make sure the pull request is noticed.
The proposal is ready for merge. Note that we can now "squash and merge" on
Github.

- Anton