[swift-evolution] Learning from SE-0025, a breeding group for Swift proposals

Hello community, I'm happy to see that SE-0169 got accepted and that we've patched the issues of SE-0025. But it's been a difficult process. And I can't stop asking myself if it could have been avoided. The crux of the problem is that source-compatibility is now becoming a very strong requireme

Re: [swift-evolution] Learning from SE-0025, a breeding group for Swift proposals

> On Apr 18, 2017, at 1:00 AM, David Hart via swift-evolution > wrote: > > I'm happy to see that SE-0169 got accepted and that we've patched the issues > of SE-0025. But it's been a difficult process. And I can't stop asking myself > if it could have been avoided. The crux of the problem is th

[swift-evolution] Divide & Conquer Algorithms

I would like to see Swift gain something similar to Clojure’s Reducers Library. Basically this is somewhat similar to our Sequence, but for tree-based structures instead of sequential ones. It allows a series of algorithms that operate using a divide and conquer strategy, and it is easy to mas

Re: [swift-evolution] [Review] SE-0172: One-sided Ranges

> On 18 Apr 2017, at 05:40, Douglas Gregor via swift-evolution > wrote: > > What is your evaluation of the proposal? I like the principle of the proposal, but I have some concerns regarding the operators. In particular I don't like that it relies on prefix/postfix versions of the range operat

Re: [swift-evolution] Learning from SE-0025, a breeding group for Swift proposals

> On Apr 18, 2017, at 1:00 AM, David Hart via swift-evolution > wrote: > > All controversial proposals start their implementation in that version. Just one more note here, in regards to SE-0025 Its important to realize that the swift evolution process isn’t a pure democracy, or even a democr

Re: [swift-evolution] Learning from SE-0025, a breeding group for Swift proposals

> On 18 Apr 2017, at 10:12, David Waite wrote: > > >> On Apr 18, 2017, at 1:00 AM, David Hart via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> All controversial proposals start their implementation in that version. > > Just one more note here, in regards to SE-0025 > >

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

> Le 18 avr. 2017 à 02:25, Douglas Gregor via swift-evolution > a écrit : > > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md > >

Re: [swift-evolution] Learning from SE-0025, a breeding group for Swift proposals

very subjective { I see a similarity with SE-0169: It's fighting symptoms instead of causes. } (less subjective) Afaics, even members of the core team have their quarrels with the evolution process, and I want to encourage everyone to talk openly about them. Right now, we are at a turning point,

[swift-evolution] Fwd: [Review] SE-0172: One-sided Ranges

Sent from my iPhone Begin forwarded message: > From: Goffredo Marocchi > Date: 18 April 2017 at 07:33:54 BST > To: Douglas Gregor > Subject: Re: [swift-evolution] [Review] SE-0172: One-sided Ranges > > +1 seems like a slam dunk of a proposal. Far superior to the method syntax > option and n

Re: [swift-evolution] [pitch] Comparison Reform

> Le 18 avr. 2017 à 06:45, Joe Groff via swift-evolution > a écrit : > >> >> On Apr 17, 2017, at 9:40 PM, Chris Lattner wrote: >> >> >>> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution >>> wrote: >>> >>> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution w

Re: [swift-evolution] [pitch] Comparison Reform

>> then you're expecting the abstract guarantees of interchangeability and >> total ordering that implies > > > Joe, please: I'm very glad that you are expert in so many subject - I'd love > to have your job - but please keep track of average joes that have to scratch > their heads whenever th

Re: [swift-evolution] [Review] SE-0172: One-sided Ranges

> On Apr 17, 2017, at 10:40 PM, Douglas Gregor via swift-evolution > wrote: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md > > > What is your evaluation of

Re: [swift-evolution] And another access control idea

On Tue, 18 Apr 2017 at 04:56, Brent Royal-Gordon wrote: > On Apr 15, 2017, at 2:01 AM, Manolo van Ee via swift-evolution < > swift-evolution@swift.org> wrote: > > Hi All, > > I’ve been following the access control discussion a little and I had an > idea that I wanted to throw out here. I know it’

Re: [swift-evolution] Divide & Conquer Algorithms

I would like that feature too. Wouldn't this require Swift to have settled its concurrency model (which in turn would require settling ownership and borrowing)? On Tue, Apr 18, 2017 at 03:03 Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > I would like to see Swift gain so

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

Does the acceptance of SE-0169 imply any change to rules for `private extension` members, or does the core team intend such members to continue defaulting to fileprivate visibility? On Mon, Apr 17, 2017 at 19:25 Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > Proposal Li

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

The unit tests seem to show that is not needed due to the internal implementation of NSNumber. > On Apr 17, 2017, at 17:56, Xiaodi Wu wrote: > > It seems Float.init(exactly: NSNumber) has not been updated to behave > similarly? > > I would have to say, I would naively expect "exactly" to beha

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 18, 2017, at 1:34 AM, Gwendal Roué wrote: > >> >> Le 18 avr. 2017 à 06:45, Joe Groff via swift-evolution >> a écrit : >> >>> >>> On Apr 17, 2017, at 9:40 PM, Chris Lattner wrote: >>> >>> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution wrote: >>

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution > wrote: > > >> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution >>> wrote: >>> >>> For example, I expect `XCTAssertEqual(_:_:)` to b

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 18, 2017, at 11:40 AM, Ben Cohen via swift-evolution > wrote: > > >> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution >>> mailto:swift-evolution@swift.or

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 18, 2017, at 11:43 AM, Stephen Canon via swift-evolution > wrote: >> On Apr 18, 2017, at 11:40 AM, Ben Cohen via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution >>> mailto:swift-evolution@swift.org>

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

> On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution > wrote: > > It seems Float.init(exactly: NSNumber) has not been updated to behave > similarly? > > I would have to say, I would naively expect "exactly" to behave exactly as it > says, exactly. I don't think it should be a synonym

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

> On Apr 18, 2017, at 12:17 PM, Joe Groff wrote: > > >> On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> It seems Float.init(exactly: NSNumber) has not been updated to behave >> similarly? >> >> I would have to say, I would naively expect "exactly" to behave exact

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

> On Apr 18, 2017, at 9:22 AM, Stephen Canon wrote: > >> >> On Apr 18, 2017, at 12:17 PM, Joe Groff wrote: >> >> >>> On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution >>> wrote: >>> >>> It seems Float.init(exactly: NSNumber) has not been updated to behave >>> similarly? >>> >>>

Re: [swift-evolution] [pitch] Comparison Reform

> Le 18 avr. 2017 à 17:40, Joe Groff a écrit : > > >> On Apr 18, 2017, at 1:34 AM, Gwendal Roué wrote: >> >>> >>> Le 18 avr. 2017 à 06:45, Joe Groff via swift-evolution >>> a écrit : >>> On Apr 17, 2017, at 9:40 PM, Chris Lattner wrote: > On Apr 17, 2017, at 9:

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 18, 2017, at 8:40 AM, Ben Cohen via swift-evolution > wrote: > >> >> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution >>> mailto:swift-evolution@swift.or

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 18, 2017, at 9:47 AM, Gwendal Roué wrote: > > >> Le 18 avr. 2017 à 17:40, Joe Groff a écrit : >> >> >>> On Apr 18, 2017, at 1:34 AM, Gwendal Roué wrote: >>> Le 18 avr. 2017 à 06:45, Joe Groff via swift-evolution a écrit : > > On Apr 17, 2017, at 9:

Re: [swift-evolution] [pitch] Comparison Reform

I certainly don't want to restrain anyone from improving on the floating point status quo. There's surely much to do. I apologize for my not-so-constructive messages. Maybe I'm surprised that this was one of the goals of Swift. Floats and Strings are efficient ways to test comparison APIs indeed

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0172: One-sided Ranges

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md My reply: Long-time reader, first time commenter. I agree the need exists to slice up collections as d

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0172: One-sided Ranges

> On 18 Apr 2017, at 15:29, Matt Lewin via swift-evolution > wrote: > > In contrast, the proposed solution of > // half-open right-handed range > let greeting = s[.. // closed right-handed range > let withComma = s[...i] > // left-handed range (no need for half-open variant) > let location = s

[swift-evolution] SE-165: Dictionary & Set Enhancements

+1. These are great, swifty additions to the standard library. Good job Nate Cook! > Hello, Swift community! > > The review of "SE-165: Dictionary&Set Enhancements" begins now and runs > through next Tuesday, April 11th. The proposal is available here: > https://github.com/apple/swift-evolution

[swift-evolution] SE-0171: Reduce with inout

+1. Would love to see this in the standard library both for it’s improved performance and succinctness. > Hello Swift community, > > The review of “SE-0171:Reduce with inout" begins now and runs through the > Friday after next, April 14th. The proposal is available here: > https://github.com/ap

Re: [swift-evolution] [pitch] Comparison Reform

Ok, if you can name and shame the inventor of the CGFloat type ;) Sent from my iPhone > On 18 Apr 2017, at 17:58, Joe Groff via swift-evolution > wrote: > > >> On Apr 18, 2017, at 9:47 AM, Gwendal Roué wrote: >> >> >>> Le 18 avr. 2017 à 17:40, Joe Groff a écrit : >>> >>> > On Apr 18

Re: [swift-evolution] [Review] SE-0172: One-sided Ranges

> > >- What is your evaluation of the proposal? > > Strong +1, especially for the unary operators. They make code clear, concise, and elegant. Pattern matching against one-sided ranges looks great, and being able to use postfix “...” to create a sequence is niche but nifty. > >- Is the p

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0172: One-sided Ranges

> review of SE-0172 "One-sided Ranges" > > What is your evaluation of the proposal? Yes. nice addition > Is the problem being addressed significant enough to warrant a change to > Swift? Probably. Current solution not terrible but proposal better. > Does this proposal fit well with the feel a

Re: [swift-evolution] [pitch] Comparison Reform

> On 18 Apr 2017, at 19:06, David Sweeris via swift-evolution > wrote: > > >> On Apr 18, 2017, at 8:40 AM, Ben Cohen via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution >>> mailto:swift-evolution@swift.o

Re: [swift-evolution] [pitch] Comparison Reform

On Tue, Apr 18, 2017 at 10:40 AM, Ben Cohen via swift-evolution < swift-evolution@swift.org> wrote: > > On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution < > swift-evolution@swift.or

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

So, as I understand it, `Float.init(exactly: Double.pi) == nil`. I would expect NSNumber to behave similarly (a notion with which Martin disagrees, I guess). I don't see a test that shows whether NSNumber behaves or does not behave in that way. On Tue, Apr 18, 2017 at 11:43 AM, Philippe Hausler

Re: [swift-evolution] [pitch] Comparison Reform

To me, there are two proposals here, partly interrelated but worth considering separately. 1. Use of @_implements to allow floating point to have an IEEE implementation of operators, while still having Comparable implement strict total order across every unique value (NaN.) This includes norm

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

Sent from my iPhone > On Apr 18, 2017, at 6:58 AM, Xiaodi Wu wrote: > > Does the acceptance of SE-0169 imply any change to rules for `private > extension` members, or does the core team intend such members to continue > defaulting to fileprivate visibility? It does imply a change to "privat

Re: [swift-evolution] Learning from SE-0025, a breeding group for Swift proposals

> On Apr 18, 2017, at 12:00 AM, David Hart via swift-evolution > wrote: > > Hello community, > > I'm happy to see that SE-0169 got accepted and that we've patched the issues > of SE-0025. But it's been a difficult process. And I can't stop asking myself > if it could have been avoided. The c

Re: [swift-evolution] Learning from SE-0025, a breeding group for Swift proposals

> On 19 Apr 2017, at 06:51, Chris Lattner wrote: > > >> On Apr 18, 2017, at 12:00 AM, David Hart via swift-evolution >> wrote: >> >> Hello community, >> >> I'm happy to see that SE-0169 got accepted and that we've patched the issues >> of SE-0025. But it's been a difficult process. And I c

[swift-evolution] Low efficiency multidimensional array problem

Hello Swift community, When I used multidimensional array in swift, I found it is very low efficiency. I used in the following way : *var array = Array.init(repeating: Array.init(repeating: 0, count: 5), count: 5)* *array[0][0] = 0* I have read some posts in stack overflo

Re: [swift-evolution] SE-0171: Reduce with inout

+ 1 for me . I found that the value semantics bring some problem in swift. It is not suitable for some places. *best wishes for you * 2017-04-19 4:29 GMT+08:00 Brad Hilton via swift-evolution < swift-evolution@swift.org>: > +1. Would love to see this in the standard library both for it’s improv

Re: [swift-evolution] Low efficiency multidimensional array problem

It might be helpful if you showed a bit more of the code you’re working on, so that we can better see what you’re trying to do. Is there any operation in particular that is slow? Also, CC’ing swift-users since I think it belongs there. Saagar Jha > On Apr 18, 2017, at 22:57, Hbucius Smith via