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

> On Jul 7, 2016, at 11:53 AM, Anton Zhilin via swift-evolution > wrote: > > 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 spe

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

I look forward to the final design as i find these precedence groups a great additions. Regards (From mobile) > On Jul 7, 2016, at 9:02 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Thu, Jul 7, 2016 at 11:28 AM, Dmitri Gribenko via swift-evolution >> wrote: >> On Thu, Jul 7, 2016 at 9:2

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

It really looks like the process is showing its limits... with so many people, some with knowledge of compiler imposed limitations, most with a laundry list of their favorite features from other languages, and even a few aspiring at finally having anti-gravity boots into the compiler, it seems s

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

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 wrote: > > On Jul 7, 2016, at 9:23 AM, Dmitri Gribenko via swift-evolution > > wrote: > >> Proposal link: > >> > >> > >> > https://github.com/app

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

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 Coal

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

On Thu, Jul 7, 2016 at 9:27 AM, John McCall wrote: > On Jul 7, 2016, at 9:23 AM, Dmitri Gribenko via swift-evolution > 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 th

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

> On Jul 7, 2016, at 9:23 AM, Dmitri Gribenko via swift-evolution > wrote: > > Proposal link: > > > > https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md > > > > >

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

> 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

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

Alternatives: precedencegroup MultiplicativePrecedence : left where Self > AdditivePrecedence precedencegroup MultiplicativePrecedence { Self > AdditivePrecedence

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

I think higherThan and lowerThan are not excessively wordy, they are the correct mathematical term, and the IDE can help you autocomplete that else it is a quick snippet job. Sent from my iPhone > On 2 Jul 2016, at 22:52, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > On painting t

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

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

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

Joe Groff via 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 d

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

John McCall via 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 po

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

On Thu, Jun 30, 2016 at 2:09 PM, Matthew Johnson wrote: > > On Jun 30, 2016, at 1:48 PM, Xiaodi Wu wrote: > > 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. >

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

> On Jun 30, 2016, at 1:48 PM, Xiaodi Wu wrote: > > 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

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

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

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

> On Jun 30, 2016, at 11:25 AM, Matthew Johnson wrote: > On Jun 30, 2016, at 1:08 PM, John McCall via swift-evolution > wrote: > >>> On Jun 30, 2016, at 2:34 AM, Anton Zhilin via swift-evolution >>> wrote: >>> https://github.com/apple/swift-evolution/blob/master/proposals >>> /0077-operator-p

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

Sent from my iPad On Jun 30, 2016, at 1:08 PM, John McCall via swift-evolution wrote: >> On Jun 30, 2016, at 2:34 AM, Anton Zhilin via swift-evolution >> wrote: >> https://github.com/apple/swift-evolution/blob/master/proposals >> /0077-operator-precedence.md >> >> Idea #1 >> >> There is a

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

> On Jun 30, 2016, at 2:34 AM, Anton Zhilin via swift-evolution > 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.

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

> On Jun 30, 2016, at 2:34 AM, Anton Zhilin via swift-evolution > 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 t

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

> On Jun 30, 2016, at 7:58 AM, Anton Zhilin via swift-evolution > wrote: > > Matthew Johnson via 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

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

Matthew Johnson via 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 Abrah

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

Sent from my iPad > On Jun 30, 2016, at 4:34 AM, Anton Zhilin via swift-evolution > 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. What is

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

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

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

> 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

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

Hello Swift community, The second review of “Improved operator declarations” begins now and runs through July 4, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md The previous version of the proposal that was reviewed