Hi Susan, As I mentioned on your original pull request, coroutines are closely related to async and other concurrency forms. That entire space is out of scope for Swift 3, so we should wait until fall 2016 to pick up discussion on this and related topics.
-Chris > On Dec 22, 2015, at 12:16 PM, Andrew Bennett via swift-evolution > <[email protected]> wrote: > > Hi Daniel, > > I've heard many great things about goroutines, and I definitively think their > advantages should be considered in the design of Swift's concurrency. > > I haven't used goroutines much so I may be incorrect, but I don't think they > can be used to efficiently represent a generator like the proposal suggests. > > The generator described in the proposal has the following properties: > * it is basically just syntactic sugar > * new elements are generated lazily > * the length doesn't need to be known at initialisation > * it uses existing function syntax in the caller > * it can all run on one thread > * concurrency considerations may be limited to safely updating the state > variable from more than one thread > > Maybe goroutines can be equivalent if the compiler can optimise it down to a > generator. This proposal is basically syntactic sugar to concisely define a > generator. Goroutines probably aren't a concise replacement for that sugar. > > > On Wednesday, 23 December 2015, Daniel Valls Estella <[email protected] > <mailto:[email protected]>> wrote: > > Ok, > > But I think goroutines are not really threads (are faster and cheaper enought > to make a diference) and channels are more like filedescriptors than signals, > you stream data throught these. > > Thanks for your answer! > > Daniel > > Daniel Valls Estella · tel. 659.910.830 · [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');> >> El 22 des 2015, a les 11:50, Susan Cheng <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> va escriure: >> >> It's a little difference with goroutine. Go using threads and signal. >> My implementation is following C# methods that MS staff tells me. >> >> Daniel Valls Estella <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> 於 2015年12月22日星期二 寫道： >> I think it’s better to take as a reference the Go language and his >> goroutines and channels. >> >> Not just to face these type of problems but also to take new architectural >> aproches to build software solutions. >> >> >> refs: >> >> https://tour.golang.org/concurrency/1 <https://tour.golang.org/concurrency/1> >> https://tour.golang.org/concurrency/2 <https://tour.golang.org/concurrency/2> >> https://tour.golang.org/concurrency/5 <https://tour.golang.org/concurrency/5> >> https://youtu.be/f6kdp27TYZs <https://youtu.be/f6kdp27TYZs> >> >> >> What you think? >> >> Daniel >> >> Daniel Valls Estella · tel. 659.910.830 · [email protected] <> >>> El 22 des 2015, a les 8:33, Andrew Bennett via swift-evolution >>> <[email protected] <>> va escriure: >>> >>> Great proposal! I'm all for this, I think your proposed implementation is >>> pretty good too. >>> >>> It would be interesting to expand the proposal to consider more cases in >>> more detail: >>> * Concurrency >>> * SequenceType versus GeneratorType >>> * Should a language feature depend on the Standard Library >>> (GeneratorType)? Alternatives: >>> + func myFunction -> () -> T? >>> + func myFunction -> () -> (myFunction_State, myFunction_State -> T?) >>> * What happens if you write: guard ... else { yield ... } >>> * Use an enum for the state that encapsulates all possible variables in >>> each state >>> >>> If you're not familiar with it, there's another thread that discussed >>> similar here: >>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001872.html >>> >>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001872.html> >>> >>> In particular you may be interested in Chris Lattner's comment: >>> I’m very interested in this, but it is clearly out of scope for Swift 3. It >>> should also be considered alongside whatever async/concurrency approach we >>> tackle (likely in swift 4). >>> >>> Either way it's worth discussing and working towards :) >>> >>> On Tue, Dec 22, 2015 at 6:03 PM, Félix Cloutier <[email protected] >>> <>> wrote: >>> There's probably some additional work to do on the proposal document, but I >>> would like to see coroutines in Swift too. The feature has been very >>> successful in other languages like Python and C#, and unless I'm mistaken, >>> work is being done to standardize it in C++. >>> >>> Generators are one use case, but resumable functions in general can also be >>> used to make async code look prettier. >>> >>> Félix >>> >>>> Le 22 déc. 2015 à 01:47:05, Susan Cheng via swift-evolution >>>> <[email protected] <>> a écrit : >>>> >>>> here is my proposal for swift lang >>>> >>>> https://github.com/SusanDoggie/swift-evolution/blob/master/proposals/0018-coroutine-for-swift.md >>>> >>>> <https://github.com/SusanDoggie/swift-evolution/blob/master/proposals/0018-coroutine-for-swift.md> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
