Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

2017-08-17 Thread Robert Bennett via swift-evolution
Chris mentions that the intent was to mimic a default implementation in a constrained protocol extension, with one extension per type that doesn’t define its own ==/hashValue while conforming to Equatable/Hashable. Constrained extensions are allowed to use type information from the constraint,

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

2017-08-17 Thread Jonathan Hull via swift-evolution
+1 > On Aug 17, 2017, at 2:38 AM, Adrian Zubarev via swift-evolution > wrote: > > This is a small pitch which I will abandon if there is not much appetite for > such improvement. ;) > > I would like to propose an improvement to an initializer of all collection >

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

2017-08-17 Thread Haravikk via swift-evolution
> On 17 Aug 2017, at 00:06, Robert Bennett via swift-evolution > wrote: > > How do unstable hash values play with Codable? If you encode and save a Set, > might you have problems interacting with it in the future? (This is more a > Codable question than Hashable,

[swift-evolution] [Pitch] Improve `init(repeating:count)`

2017-08-17 Thread Adrian Zubarev via swift-evolution
This is a small pitch which I will abandon if there is not much appetite for such improvement. ;) I would like to propose an improvement to an initializer of all collection types that provide: init(repeating repeatedValue: Element, count: Int). This change is meant to support reference type

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

2017-08-17 Thread Robert Bennett via swift-evolution
Alternatively, instead of replacing the current definition with an autoclosure version, we could leave the current version in place and add a version taking a function. This could be especially useful when you’ve defined a function like `makeMySpecialKindOfButton() -> UIButton` that does a lot

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

2017-08-17 Thread Xiaodi Wu via swift-evolution
This would be very source-breaking, no? On Thu, Aug 17, 2017 at 04:47 Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > +1 > > On Aug 17, 2017, at 2:38 AM, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote: > > This is a small pitch which I will abandon

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

2017-08-17 Thread Haravikk via swift-evolution
> On 17 Aug 2017, at 10:38, Adrian Zubarev via swift-evolution > wrote: > > This is a small pitch which I will abandon if there is not much appetite for > such improvement. ;) > > I would like to propose an improvement to an initializer of all collection > types

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

2017-08-17 Thread Adrian Zubarev via swift-evolution
In terms of functionality yes potentially a breaking change, because the behavior would change for objects that were initialized through the passed expression. Personally it always bugged me that it does not work for objects and forced map usage over a range to create an array of different

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

2017-08-17 Thread Haravikk via swift-evolution
> On 17 Aug 2017, at 11:42, Robert Bennett wrote: > > Chris mentions that the intent was to mimic a default implementation in a > constrained protocol extension, with one extension per type that doesn’t > define its own ==/hashValue while conforming to

Re: [swift-evolution] pitch: Unified libc import (again)

2017-08-17 Thread Taylor Swift via swift-evolution
Python’s os.path is a nice abstract model for doing path manipulations. Maybe Swift could get a struct like `Filepath` or something on which these operations could be done. On Thu, Aug 17, 2017 at 6:47 PM, Taylor Swift wrote:

[swift-evolution] [Concurrency] Signals — reactive-like threads

2017-08-17 Thread Félix Fischer via swift-evolution
I haven’t used Async-Await ever, so the following will probably be moot. But here I go: I learned concurrency at Uni with C#. Most of it was meh/okay. The gist of it is this: - You have instances of Threads. Each one recieves a function to start in. When they return, they end. - Threads can be

Re: [swift-evolution] [Concurrency] async/await + actors

2017-08-17 Thread Chris Lattner via swift-evolution
> On Aug 17, 2017, at 3:24 PM, Chris Lattner wrote: > > Hi all, > > As Ted mentioned in his email, it is great to finally kick off discussions > for what concurrency should look like in Swift. This will surely be an epic > multi-year journey, but it is more important to

[swift-evolution] [Concurrency] async/await + actors

2017-08-17 Thread Chris Lattner via swift-evolution
Hi all, As Ted mentioned in his email, it is great to finally kick off discussions for what concurrency should look like in Swift. This will surely be an epic multi-year journey, but it is more important to find the right design than to get there fast. I’ve been advocating for a specific

Re: [swift-evolution] pitch: Unified libc import (again)

2017-08-17 Thread Taylor Swift via swift-evolution
On Thu, Aug 17, 2017 at 3:50 PM, Daniel Dunbar wrote: > > > On Aug 17, 2017, at 9:26 AM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > > > I know this has come up before without any action, but having the > standard C library be packaged

Re: [swift-evolution] [Concurrency] async/await + actors

2017-08-17 Thread Rod Brown via swift-evolution
Hi Chris, I love what I’ve read so far. I just have one curiosity from my cursory look over the proposal. It seems that in transitioning API to an Async Await system, the completion handler’s type becomes the return type. How would you handle bridging in Foundation API that already has a

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

2017-08-17 Thread Xiaodi Wu via swift-evolution
This is, I would argue, much too limiting in the way of semantics and not at all required by “map”. It’s unclear to me how _any_ result with reference semantics or any function with side effects could be used in a way that comports with that definition. On the other hand, just as y = 0x is a

Re: [swift-evolution] pitch: Unified libc import (again)

2017-08-17 Thread Taylor Swift via swift-evolution
I don’t think the “is this library functionality or standard library functionality” argument is worth having, but if stdout and stdin are first-class citizens in the Swift world, so should stderr. As for bringing Foundation into the discussion, you can’t really talk about Foundation without also

[swift-evolution] kicking off concurrency discussions

2017-08-17 Thread Ted Kremenek via swift-evolution
Hi everyone, One of the goals for Swift 5 is to start laying the *groundwork* for a concurrency model. >From https://github.com/apple/swift-evolution: > Laying groundwork for a new concurrency model. We will lay groundwork for a > new concurrency model, especially as needed for ABI

Re: [swift-evolution] pitch: Unified libc import (again)

2017-08-17 Thread Xiaodi Wu via swift-evolution
IMO, you’re touching on at least three or four separate topics here. Daniel touched on several, but just some comments/questions: * Standard error output is something that’s been discussed here previously. I believe the last pitch had something like StandardError being added to the standard

Re: [swift-evolution] [Concurrency] async/await + actors

2017-08-17 Thread Chris Lattner via swift-evolution
> On Aug 17, 2017, at 4:56 PM, Rod Brown wrote: > > > Hi Chris, > > I love what I’ve read so far. I just have one curiosity from my cursory look > over the proposal. > > It seems that in transitioning API to an Async Await system, the completion > handler’s type

Re: [swift-evolution] [Concurrency] async/await + actors

2017-08-17 Thread Chris Lattner via swift-evolution
> On Aug 17, 2017, at 5:47 PM, William Jon Shipley > wrote: > > I think the comments on “prettify()” are from an earlier version of the > sample code? The way it’s called it doesn’t look like it’d access theList at > all. The body of the function is omitted :-)

Re: [swift-evolution] pitch: Unified libc import (again)

2017-08-17 Thread Taylor Swift via swift-evolution
Okay I can sense this thread getting derailed so I’ll try to address your comments one by one. * stderr should go wherever stdin and stdout go. Since it’d be silly for a function like `print(_:separator:terminator:)` or ` readLine(strippingNewline:)` to live anywhere but the standard library,

Re: [swift-evolution] [Concurrency] async/await + actors

2017-08-17 Thread Chris Lattner via swift-evolution
> On Aug 17, 2017, at 7:28 PM, Yuta Koshizawa wrote: > > I think we also need `reasync` like `rethrows`. > > extension Sequence { > func map(_ transform: (Element) async throws -> T) reasync > rethrows -> [T] { ... } > } > > let urls: [URL] = ... >

Re: [swift-evolution] [Concurrency] async/await + actors

2017-08-17 Thread Chris Lattner via swift-evolution
On Aug 17, 2017, at 7:39 PM, Matthew Johnson wrote: > This is fantastic! Thanks for taking the time to write down your thoughts. > It’s exciting to get a glimpse at the (possible) road ahead. Happy to. > In the manifesto you talk about restrictions on passing

Re: [swift-evolution] [Concurrency] async/await + actors

2017-08-17 Thread Zach Waldowski via swift-evolution
On Thu, Aug 17, 2017, at 10:04 PM, Chris Lattner via swift-evolution wrote:> That said, I don’t feel like I have enough data to have a strong > opinion on it. The missing link for me is exactly how pervasive the > non-throwing cocoa completion handlers are. If it turns out that > people would

Re: [swift-evolution] [Concurrency] async/await + actors

2017-08-17 Thread William Jon Shipley via swift-evolution
I’m curious about this statement at the end in "alternatives": > The proposed design eliminates the problem of calling an API (without knowing > it is async) and getting a Future back instead of the expected T result > type. C# addresses this by suggesting that all async methods have their name

Re: [swift-evolution] [Concurrency] async/await + actors

2017-08-17 Thread William Jon Shipley via swift-evolution
I think the comments on “prettify()” are from an earlier version of the sample code? The way it’s called it doesn’t look like it’d access theList at all. actor TableModel { let mainActor : TheMainActor var theList : [String] = [] { didSet {

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

2017-08-17 Thread Robert Bennett via swift-evolution
Xiaodi, you pretty much took the words out of my mouth. I was going to suggest a Count collection whose Element was Void and with the sole initializer init(_ count: Int). The type would just contain its count and pretty much fake its collection interface, in the sense that no elements are

Re: [swift-evolution] [Concurrency] async/await + actors

2017-08-17 Thread Rod Brown via swift-evolution
> On 18 Aug 2017, at 9:56 am, Rod Brown via swift-evolution > wrote: > > > Hi Chris, > > I love what I’ve read so far. I just have one curiosity from my cursory look > over the proposal. > > It seems that in transitioning API to an Async Await system, the

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

2017-08-17 Thread Erica Sadun via swift-evolution
What people are doing is taking a real set of values (1, 2, 3, 4, 5, for example), then discarding them via `_ in`, which is different from `Void -> T` or `f(x) = 0 * x`. The domain could just as easily be (Foo(), "b", , UIColor.red, { x: Int in x^x }). There are too many semantic shifts away

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

2017-08-17 Thread Xiaodi Wu via swift-evolution
On Thu, Aug 17, 2017 at 8:06 PM, Erica Sadun wrote: > > On Aug 17, 2017, at 6:56 PM, Xiaodi Wu wrote: > > On Thu, Aug 17, 2017 at 7:51 PM, Erica Sadun wrote: > >> What people are doing is taking a real set of values (1, 2, 3, 4,

Re: [swift-evolution] pitch: Unified libc import (again)

2017-08-17 Thread Xiaodi Wu via swift-evolution
On Thu, Aug 17, 2017 at 6:46 PM, Taylor Swift wrote: > I don’t think the “is this library functionality or standard library > functionality” argument is worth having, but if stdout and stdin are > first-class citizens in the Swift world, so should stderr. > > As for

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

2017-08-17 Thread Xiaodi Wu via swift-evolution
On Thu, Aug 17, 2017 at 8:25 PM, Erica Sadun wrote: > `repeatElement((), count: 5)` is better than `1 ... 5`, but > `Count(3).map({ UIView() })` is far more elegant. I'd still probably go > with an array initializer or `5.elements(of: UIView())`. I don't think I'm >

Re: [swift-evolution] typed throws

2017-08-17 Thread Chris Lattner via swift-evolution
Splitting this off into its own thread: > On Aug 17, 2017, at 7:39 PM, Matthew Johnson wrote: > One related topic that isn’t discussed is type errors. Many third party > libraries use a Result type with typed errors. Moving to an async / await > model without also

Re: [swift-evolution] [Concurrency] async/await + actors

2017-08-17 Thread William Jon Shipley via swift-evolution
Oh, I see that this is addressed in the “ x = await (await foo()).bar()” example. That IS ugly. -W___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Concurrency] async/await + actors

2017-08-17 Thread Matthew Johnson via swift-evolution
Hi Chris, This is fantastic! Thanks for taking the time to write down your thoughts. It’s exciting to get a glimpse at the (possible) road ahead. In the manifesto you talk about restrictions on passing functions across an actor message. You didn’t discuss pure functions, presumably because

Re: [swift-evolution] pitch: Unified libc import (again)

2017-08-17 Thread Taylor Swift via swift-evolution
On Thu, Aug 17, 2017 at 11:19 PM, Xiaodi Wu wrote: > On Thu, Aug 17, 2017 at 22:06 Taylor Swift wrote: > >> Okay I can sense this thread getting derailed so I’ll try to address your >> comments one by one. >> >> * stderr should go wherever stdin and

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

2017-08-17 Thread Rintaro Ishizaki via swift-evolution
I don't think it's worthwhile adding new API. I think this is simple enough: let views = Array(AnyIterator(UIView.init).prefix(3)) 2017-08-17 21:04 GMT+09:00 Robert Bennett via swift-evolution < swift-evolution@swift.org>: > Alternatively, instead of replacing the current definition with an >

[swift-evolution] pitch: Unified libc import (again)

2017-08-17 Thread Taylor Swift via swift-evolution
I know this has come up before without any action, but having the standard C library be packaged under `Darwin` on OSX and `Glibc` under Linux is something that’s really becoming an issue as the Swift package ecosystem matures. Right now a lot of packages are a lot less portable than they could be

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

2017-08-17 Thread Tony Allevato via swift-evolution
Couldn't this be rewritten more simply today as: Array((0..<3).map { index in MyView(forIndex: index) }) And the version that doesn't need the index could be written: Array((0..<3).map { _ in UIView() }) The AnyIterator approach posted above is also nice—I wouldn't have thought of that

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

2017-08-17 Thread Erica Sadun via swift-evolution
Also, for those of you here who haven't heard my previous rant on the subject, I dislike using map for generating values that don't depend on transforming a domain to a range. (It has been argued that `_ in` is mapping from `Void`, but I still dislike it immensely) Here are the ways that I

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

2017-08-17 Thread Jonathan Hull via swift-evolution
The closure should go on the end though… > On Aug 17, 2017, at 8:40 AM, Christopher Kornher via swift-evolution > wrote: > > We might as well add the index to the call so elements can be created from > other lists, etc. > > Array(repeatedlyCalling: { (index:Int)

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

2017-08-17 Thread Tony Allevato via swift-evolution
On Thu, Aug 17, 2017 at 9:20 AM Ross O'Brien wrote: > (0..<3).map{ _ in UIView() } - map already returns an Array. > > Array((0..<3).map{ _ in UIView() }) is redundant. > Ah, right, thanks for pointing that out. I couldn't remember off the top of my head whether it

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

2017-08-17 Thread Chris Lattner via swift-evolution
> On Aug 17, 2017, at 5:00 AM, Haravikk via swift-evolution > wrote: > > >> On 17 Aug 2017, at 11:42, Robert Bennett > > wrote: >> >> Chris mentions that the intent was to mimic a default implementation in a

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

2017-08-17 Thread Ross O'Brien via swift-evolution
(0..<3).map{ _ in UIView() } - map already returns an Array. Array((0..<3).map{ _ in UIView() }) is redundant. I've fallen foul before, of trying to create an array of six buttons and getting an array of one button six times; I think that should be easier. But if each button corresponds to an

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

2017-08-17 Thread Erica Sadun via swift-evolution
`repeatElement((), count: 5)` is better than `1 ... 5`, but `Count(3).map({ UIView() })` is far more elegant. I'd still probably go with an array initializer or `5.elements(of: UIView())`. I don't think I'm overstating how common this pattern is, and `Array(repeating:count:)` feels _close_ but

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

2017-08-17 Thread Erica Sadun via swift-evolution
> On Aug 17, 2017, at 7:38 PM, Xiaodi Wu wrote: > > On Thu, Aug 17, 2017 at 8:25 PM, Erica Sadun > wrote: > `repeatElement((), count: 5)` is better than `1 ... 5`, but `Count(3).map({ > UIView() })` is far more elegant.

Re: [swift-evolution] [Concurrency] async/await + actors

2017-08-17 Thread Yuta Koshizawa via swift-evolution
I think we also need `reasync` like `rethrows`. extension Sequence { func map(_ transform: (Element) async throws -> T) reasync rethrows -> [T] { ... } } let urls: [URL] = ... let foos: [Foo] = await try urls.map { await try downloadFoo($0) } -- Yuta

Re: [swift-evolution] [Concurrency] async/await + actors

2017-08-17 Thread Yuta Koshizawa via swift-evolution
I think we also need `reasync` like `rethrows`. Sorry, I found it was referred in "rethrows could be generalized to support potentially async operations". -- Yuta ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [Concurrency] async/await + actors

2017-08-17 Thread Chris Lattner via swift-evolution
On Aug 17, 2017, at 5:51 PM, Xiaodi Wu wrote: > > Oh, also, one relatively short term piece of this model is a proposal for > adding an async/await model to Swift (in the form of general coroutine > support). Joe Groff and I wrote up a proposal for this, here: >

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

2017-08-17 Thread Max Moiseev via swift-evolution
> On Aug 17, 2017, at 10:05 AM, Erica Sadun via swift-evolution > wrote: > > Also, for those of you here who haven't heard my previous rant on the > subject, I dislike using map for generating values that don't depend on > transforming a domain to a range. (It has

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

2017-08-17 Thread Haravikk via swift-evolution
> On 17 Aug 2017, at 18:04, Chris Lattner wrote: >> On Aug 17, 2017, at 5:00 AM, Haravikk via swift-evolution >> > wrote: >>> On 17 Aug 2017, at 11:42, Robert Bennett >>