<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Because stackful coroutines quickly start to quickly approximate threading, I didn’t think they were appropriate to propose at this time. That said:</div><div class=""><br class=""></div><div class="">I think you would probably want something like Coroutine.create<String,()> so that the String->() and ()->String interfaces of the two objects can be generated. Likewise, in your example I believe a Coroutine-related protocol instance should be passed in that exposes a yield(value:String) -> () method </div><div class=""><br class=""></div><div class="">Coroutines and generator functions both involve additional rules for cleanup. Imagine a coroutine or generator which walks a file or network stream, returning individual lines of text. The code using .resume() may stop reading once they recognize the line they need or encounter an error, but the system still needs to be able to reclaim the coroutine as well as close/reclaim the local/network stream resources.</div><div class=""><br class=""></div><div class=""><div class="">The references need to be set up in such a way that objects are reclaimed in a predictable order, and defer blocks would probably be supported and run, to make such control flow more obvious. This compiler support which would be required whether you were doing (sequence) generator functions or “full” coroutines. In the generator case, such cleanup needs to be moved to the teardown of your state objects. It is possible some of the cleanup for full coroutines would be shared with pre-existing thread termination support.</div></div><div class=""><br class=""></div><div class="">Finally - any calls to yield might never resume, and it is possible your code will transition between processors/parent threads on the subsequent resume. This pushes me toward promoting a keyword vs using Coroutine.yield, and restricting use of the yield keyword to make such behavior more obvious (in the same way throws must be declared and try must be used when calling an error-throwing method today)</div><div class=""><br class=""></div><div class="">-DW</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Dec 12, 2015, at 9:43 PM, Taras Zakharko via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Personally, I am agains generators (its quite specific syntactic sugar that adds a lot of complexity), but I would be all for a comprehensive coroutine library*. One can model it after Lua’s coroutines (<a href="http://www.lua.org/pil/9.1.html" class="">http://www.lua.org/pil/9.1.html</a>), which works well with the existing syntax. Your example becomes something like:</div><div class=""><br class=""></div><div class="">helloGenerator = Coroutine.create<()->String>({name:String -> () in </div><div class=""> Coroutine.yield(“Hello”)</div><div class=""> Coroutine.yield(name ?? “World”)</div><div class="">})</div><div class=""><br class=""></div><div class="">this generates a class instance with a resume ()->String? method that can be used to retrieve the values. You can also pass values via resume (they will be then available as results of coroutine.yield)</div><div class=""><br class=""></div><div class="">One can than use helloGenerator.resume() to get the values (which can be easily wrapped in a sequence etc).</div><div class=""><br class=""></div><div class="">Benefits of this approach: no need for significant syntactic change (although a coroutine keyword could be introduced instead of func to wrap the above declaration), the coroutine functions are offloaded to a type rather than syntactic construct, type safety is quite easy to preserve. Still, its far from being a trivial thing to implement as it would require support of continuations on the compiler level. </div><div class=""><br class=""></div><div class="">Cheers, </div><div class=""><br class=""></div><div class=""> Taras</div><div class=""><br class=""></div><div class="">*Yes, current generators in Python are essentially coroutines but I think it important to keep the terminology clean. Generators are intended first and foremost as lazy sequence, well, generators. Coroutines are a much more versatile construct. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div>On Fri, Dec 11, 2015 at 18:21 PM, David Waite via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">Looking for feedback on crafting a proposal adding generator functions to Swift. I understand this will likely be a very involved proposal at the language level, although I actually don’t know the complexity of the change within the Swift compiler itself.
</pre></div><div class=""><br class=""></div></div></blockquote>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=nE9rxSXA5G4kxsTVkgv43vFcOQoCM-2FU-2BigXPSqPoICKF8-2Bp95ky8ULwJBPf3Gzlmay-2BdVhF3-2BBFzOQmwh7a3nrgpeaj20wtwnIPMO1H5rFobY7LeJPw5QIJObM88InQ1b979dnOz5fGFdTZTf3bI13dpgLHVSDGCYey2RwMCE1gWbdTfTGU-2BEVdfZEhtuQ1EtMq8e-2BDX-2FUyhkEzQ7o2hn-2Bo9tqjh1D-2BTtf3oUc5EPnk-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>