Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

> On Jun 9, 2016, at 12:31 PM, Антон Жилин via swift-evolution > wrote: > > I'm starting to worry about the proposal, too. Any news? > > - Anton They posted: The core team has caught up except for three proposals that have gone through the review period, but

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

I'm starting to worry about the proposal, too. Any news? - Anton 2016-05-31 1:07 GMT+03:00 Антон Жилин : > I assume that Core team is scheduling a discussion or already discussing > the proposal, and that really takes time in our case. > > In reply to Brent, I think that

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

I assume that Core team is scheduling a discussion or already discussing the proposal, and that really takes time in our case. In reply to Brent, I think that we can start requiring `public` if (when?) operator visibility levels are added. - Anton 2016-05-24 13:53 GMT+03:00 Brent Royal-Gordon

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

Any updates about the status of this review? Thanks, Brandon > On May 17, 2016, at 11:30 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0077: Improved operator declarations" begins now and runs > through May 23. The

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

> > Can you qualify them with module names? > Right now, I guess, no, although that would be nice to have. I agree that > this can be discussed later. I wonder if we should force people today to put a `public` keyword on their `operator` and `precedence` (or whatever) declarations, so that when

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

> On May 23, 2016, at 13:10, Антон Жилин via swift-evolution > wrote: > > @CoreTeam Please, don't forget to merge pull request with fixes and > alternatives from review period. > > @AnyoneElse Today is (formally) the last day of review. It may be your last >

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

@CoreTeam Please, don't forget to merge pull request with fixes and alternatives from review period. @AnyoneElse Today is (formally) the last day of review. It may be your last chance! Apple repo link: https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md My

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

Sent from my iPad > On May 21, 2016, at 7:48 AM, Антон Жилин wrote: > > Updated the proposal: > https://github.com/Anton3/swift-evolution/blob/master/proposals/0077-operator-precedence.md > > I included many of alternate solutions. Please, reply, if I missed any. > >

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

Looking real good (especially the alternative section :P)! What's the rationale for using upper and lower? My objection to this is how it can be read: "precedence addition associativity left upper XXX lower XXX" I think upper and lower kind of break the flow of how it is read. This seems

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

> On May 20, 2016, at 4:56 PM, Антон Жилин wrote: > > 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

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

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

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

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 : > > On May 20, 2016, at 3:51 PM, John McCall wrote: > > On May

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

> On May 20, 2016, at 3:51 PM, John McCall wrote: > >> On May 20, 2016, at 1:25 PM, Антон Жилин > > wrote: >> Inline: >> >> 2016-05-20 20:58 GMT+03:00 John McCall > >:

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

> On May 20, 2016, at 1:25 PM, Антон Жилин wrote: > Inline: > > 2016-05-20 20:58 GMT+03:00 John McCall >: > The transitivity rule plus the ability to define precedence relationships in > both directions on a new

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

> On May 17, 2016, at 8:30 PM, Chris Lattner via swift-evolution > wrote: > 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] [Review] SE-0077: Improved operator declarations

Jeremy, inline: By the way, in the future directions version of the BitwiseShift group we > have > members(<<, >>) > Is that a typo? Thanks, will try to fix it. Also, just to confirm that my understanding of how this will work is > correct, the proposal seems to suggest that future

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

> On 18 May 2016, at 04:30, Chris Lattner via swift-evolution > wrote: > > > * 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

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

> 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

[swift-evolution] [Review] SE-0077: Improved operator declarations

I underline that I very much rely on the Core team to pick the "right" version of syntax. The only opinion I have is that `greaterThan` and `above` are probably better than `>`. - Anton Trent Nadeau wrote: > Although I would prefer something like: > precedence(greaterThan: LogicalAnd) > to: >

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

> * 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

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

* 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

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

* 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

[swift-evolution] [Review] SE-0077: Improved operator declarations

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