[swift-evolution] [Proposal] Custom operators

Sorry for the delay, please mail me a copy next time :) Inline: Антон Жилин: > > No new suggestions have come in 2 days, and so I have created a pull > request! > > https://github.com/apple/swift-evolution/pull/253 > 1. Assignment operators in Swift 2.2 have an `assignment` keyword: > infix

Re: [swift-evolution] [Proposal] Custom operators

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 ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [Proposal] Custom operators

Антон Жилин: > No new suggestions have come in 2 days, and so I have created a pull request! > https://github.com/apple/swift-evolution/pull/253 1. Assignment operators in Swift 2.2 have an `assignment` keyword: infix operator += { associativity right precedence 90 assignment } 2. If

Re: [swift-evolution] [Proposal] Custom operators

No new suggestions have come in 2 days, and so I have created a pull request! Here it is: https://github.com/apple/swift-evolution/pull/253 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

Re: [swift-evolution] [Proposal] Custom operators

> Am 10.04.2016 um 11:48 schrieb Антон Жилин : > >> 2016-04-10 2:27 GMT+03:00 Maximilian Hünenberger : > > [...] > >> The only minor syntax issue I have is that it is not immediately clear which >> operators belong to a precedence group. The

Re: [swift-evolution] [Proposal] Custom operators

Inline: 2016-04-10 2:27 GMT+03:00 Maximilian Hünenberger : > > Am 09.04.2016 um 19:43 schrieb Антон Жилин : > [...] > > Now, I see only 1 large question/problem risen by David Waite: > Should precedence relationships be defined inside or outside of

Re: [swift-evolution] [Proposal] Custom operators

> Am 09.04.2016 um 19:43 schrieb Антон Жилин : > [...] > 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

Re: [swift-evolution] [Proposal] Custom operators

As always, link to the proposal: https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md Without further ado, I changed syntax for declaring that an operator belongs to a group. It now looks like: infix operator <> : Comparative Next, I added a

Re: [swift-evolution] [Proposal] Custom operators

Chris, thanks for commenting, but see below: On 4/9/16 10:33, Chris Lattner via swift-evolution wrote: >> On Apr 8, 2016, at 5:16 AM, Rainer Brockerhoff via swift-evolution >> wrote: >>> - I definitely agree that a partial ordering between precedences is all >>> that

Re: [swift-evolution] [Proposal] Custom operators

> On Apr 9, 2016, at 6:36 AM, Chris Lattner via swift-evolution > wrote: > I do think it is useful to be able to specify precedence relationships > without having to define a “group”, to avoid boilerplate when you have one > operator at a logical level (“??” for

Re: [swift-evolution] [Proposal] Custom operators

On Apr 8, 2016, at 12:28 PM, Антон Жилин wrote: > The question 4 (`prefix operator ! { }` or `prefix operator !`) seems dead > simple, because if we need to declare precedence group in body of infix > operators, then other operators should have it for consistency. > >

Re: [swift-evolution] [Proposal] Custom operators

> On Apr 8, 2016, at 5:16 AM, Rainer Brockerhoff via swift-evolution > wrote: >> - I definitely agree that a partial ordering between precedences is all that >> we need/want, and that unspecified relations should be an error. >> ... >> Question for you: have you

Re: [swift-evolution] [Proposal] Custom operators

> On Apr 8, 2016, at 10:46 AM, Антон Жилин via swift-evolution > wrote: > > Right, `infix` operators without a precedence group logically should be able > to be used, just with parentheses everywhere. > > But users will most likely want to use such operators with

Re: [swift-evolution] [Proposal] Custom operators

Inline: 2016-04-09 0:17 GMT+03:00 David Waite : > Based on commit ‘01317e1a’: > > I think that it makes sense for membership to live outside of a precedence > group. An example is if I wanted to add a new assignment operator ( maybe > ??= 'assign if nil’), I would

Re: [swift-evolution] [Proposal] Custom operators

Based on commit ‘01317e1a’: I think that it makes sense for membership to live outside of a precedence group. An example is if I wanted to add a new assignment operator ( maybe ??= 'assign if nil’), I would want it to have the same precedence as existing assignment operators, including

Re: [swift-evolution] [Proposal] Custom operators

Right, `infix` operators without a precedence group logically should be able to be used, just with parentheses everywhere. But users will most likely want to use such operators with `=` without parentheses. It means, such operators should still belong to some precedence groups. I suggest that

Re: [swift-evolution] [Proposal] Custom operators

If I want to define a new operator, it seems like an unnecessary overhead to have to immediately decide which precedence group it should belong to before it can be used (assuming it doesn't interact with other operators). At the moment, new operators are implicitly assigned a 'default' precedence

Re: [swift-evolution] [Proposal] Custom operators

Thank you for your reply, Chris! I was thinking about purging directives from the proposal, and that was what I needed to do it. So, the proposal is now completely overhauled: https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md Yes, Maximilian

Re: [swift-evolution] [Proposal] Custom operators

On 4/8/16 02:59, Chris Lattner via swift-evolution wrote: >> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution >> wrote: >> Link for newcomers: >> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md >> >>

Re: [swift-evolution] [Proposal] Custom operators

> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution > wrote: > > First of all, sorry for the delay. I still hope to finish the discussion and > push the proposal to review for Swift 3.0. > Link for newcomers: >

Re: [swift-evolution] [Proposal] Custom operators

On 4/4/16 15:21, Daniel Duan via swift-evolution wrote: >> Антон Жилин via swift-evolution writes: >> >> Swift 2.2 is out, and I restart discussion on syntax for custom operators. >> I insist that this time we should focus less on linguistic aspects. > ...[snip] > > 3. It

Re: [swift-evolution] [Proposal] Custom operators

Added group version, "lessThan" problem can be solved nicely. `<`, `=`, `>` signs would be allowed there. > Should we allow "precedence(... equalTo ...)" for operators

Re: [swift-evolution] [Proposal] Custom operators

David Waite stated a major drawback of precedence groups. People will often create tiny precedence groups for their modules, and user will find that some of them should actually be the same. They will add precedenceEqualTo, but all these equivalent groups will still exist. This problem cannot

Re: [swift-evolution] [Proposal] Custom operators

Apr 5, 2016, Maximilian Hünenberger wrote: > > Am 04.04.2016 um 08:06 schrieb Антон Жилин >: > > Is it OK to have "less, equal, greater" in precedence name? > > What do you mean by OK? Other operators like == are

[swift-evolution] [Proposal] Custom operators

Sorry for breaking the thread, next time please mail me a copy :) Link to the proposal: https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md 1. I strongly agree that the numeric precedence system is not great. From > a implementation point

Re: [swift-evolution] [Proposal] Custom operators

Inline > Am 04.04.2016 um 08:06 schrieb Антон Жилин : > > Thank you for a helpful answer! > I like the idea of overriding precedence from another module. We won't need > to introduce additional keywords or visibility for operators. I will add it > to the proposal. > >

Re: [swift-evolution] [Proposal] Custom operators

> Антон Жилин via swift-evolution writes: > > Swift 2.2 is out, and I restart discussion on syntax for custom operators. > I insist that this time we should focus less on linguistic aspects. I have a few thoughts and a question regarding precedence: 1. I strongly agree

[swift-evolution] [Proposal] Custom operators

Just to clarify, with currently proposed behaviour, corresponding expressions would be parsed as follows: a + b * c // a + (b * c) a * b ^ c // a * (b ^ c) a ^ b + c // a ^ (b + c) The compiler would look only at explicitly stated precedence between two given operators and would not try to

Re: [swift-evolution] [Proposal] Custom operators

How is a non-transitive relation different from a conflict? If we use: #precedence(+, lessThan: *) #precedence(*, lessThan: ^) #precedence(^, lessThan: +) Surely that should be an error, even with none of the operators actually used? The compiler would be asked to verify two things: that the

Re: [swift-evolution] [Proposal] Custom operators

In the poposed model, all relations are not transitive. Example: #precedence(+, lessThan: *) #precedence(*, lessThan: ^) 1 ^ 2 + 3 // error #precedence(+, lessThan: ^) 1 ^ 2 + 3 // now ok Would it be better to have such indirect relations inferred? Or would it put too much responsibility on

Re: [swift-evolution] [Proposal] Custom operators

Thank you for a helpful answer! I like the idea of overriding precedence from another module. We won't need to introduce additional keywords or visibility for operators. I will add it to the proposal. I assume you mean precedence inside braces of operator, then operator scope makes sense. Self

Re: [swift-evolution] [Proposal] Custom operators

Interesting model! If I understand correctly: this changes the precedence from being based on a numeric value, to being represented as a bit of a DAG of precedence groups. A precedence group is defined implicitly for each operator, with one group around each set of operators where equalTo has

Re: [swift-evolution] [Proposal] Custom operators

See inline > Am 03.04.2016 um 13:26 schrieb Ross O'Brien via swift-evolution > : > > There is a problem here of duplicated operators or custom precedence, and how > that gets passed between modules. > Assume there are three modules, A, B and C. B defines a custom

Re: [swift-evolution] [Proposal] Custom operators

That doesn't sound future-proof. If it was in place and Range hadn't existed since the earliest Swift public release, it wouldn't be possible to define its precedence now. Félix > Le 3 avr. 2016 à 11:41:00, Ben Rimmington via swift-evolution > a écrit : > >

Re: [swift-evolution] [Proposal] Custom operators

Another way to eliminate numerical precedence is by using keywords: infix operator << { associativity none exponentiative } infix operator * { associativity left

Re: [swift-evolution] [Proposal] Custom operators

Right, the proposal in its current form does not really aim to resolve such conflicts, although it makes them occur less often by "merging" precedence and associativity when possible. At first, I also tried to resolve such conflicts by naming operators. But I found that compiler instructions will

Re: [swift-evolution] [Proposal] Custom operators

In these case of module operator conflicts perhaps there could be a way we could import these operators ? Likes a #importOperators(OtherModule) or some kind of build flag. *___* *James⎥Future Prime Minister* *ja...@supmenow.com ⎥supmenow.com

Re: [swift-evolution] [Proposal] Custom operators

There is a problem here of duplicated operators or custom precedence, and how that gets passed between modules. Assume there are three modules, A, B and C. B defines a custom operator **. A and C each define a custom operator ++, and their meanings are different (though, even if their meanings

Re: [swift-evolution] [Proposal] Custom operators

I think this is a great suggestion! One potential problem I can see (if I understood this correctly) is that modules are allowed to set up their own precedence rules for operators defined elsewhere. I think this might lead to some difficult to debug errors if a developer of one module (who is

Re: [swift-evolution] [Proposal] Custom operators

> On 3 Apr 2016, at 11:45, Антон Жилин wrote: > > > Assuming these are defined in separate modules, how do we determine the > > order of • and ~? > > By default, priority between any two operators is undefined. If two modules > don't know about each other, but the

Re: [swift-evolution] [Proposal] Custom operators

> Assuming these are defined in separate modules, how do we determine the order of • and ~? By default, priority between any two operators is undefined. If two modules don't know about each other, but the user wishes to prioritize them, then he will write: #precedence(•, lessThan: ~) If •

Re: [swift-evolution] [Proposal] Custom operators

Interesting, I like the idea of changing how precedence is defined, but I’m curious how under the new scheme we would go about inserting a new operator unambiguously? For example: #precedence(•, lessThan: *) #precedence(~, lessThan: *) Assuming these are defined in separate