<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 13, 2017, at 9:52 PM, John McCall via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">SIL now has some minimal representational support for coroutines, and while there's significantly more to do there, I'd like to simultaneously kick off a conversation about how best to represent them at the AST level.<div class=""><br class=""></div><div class="">Only special kinds of declarations can be coroutines. In the first stage, that will exclusively be read/modify accessors; eventually we will add generators, but maybe not in Swift 5. These declarations are not referenced directly in the AST. In fact, accessor coroutine types never need to be first-class in the function type system, and generator types... well, that depends on the generator language design. Therefore, we <i class="">could</i> make this purely a special case in both SIL constant-type lowering and various places in Sema. However, I think it would be better to represent it more faithfully in the AST, in the interest of not creating unnecessary technical debt. Since coroutine types still wouldn't be first-class, we could still safely ignore them in systems like the constraint solver and runtime type metadata.</div></div></div></blockquote><div><br class=""></div><div>I don't have a full sense of the tradeoffs yet, and you've probably thought about the tradeoffs a lot more, but my initial reaction to this is a bit hesitant. The other places we have not-really-first-class types in the type system, like InoutType and LValueType, have been sources of tech debt in their own way when they occasionally manage to leak out of their intended corners. Maybe that's not a concern so much since you can't ever directly reference an accessor decl in expressions.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">The basic structure of an accessor coroutine type is:</div><div class=""> - It can still have arbitrary parameters as normal (because of subscripts).</div><div class=""> - The result type is always ().</div><div class=""> - There is one yield.</div><div class=""> - The yield can be inout, owned, or shared.</div><div class=""><br class=""></div><div class="">It is reasonable to anticipate adding generators. Generators should be able to yield multiple values independently, each of them with its own ownership. (For example, an "enumerated" mutating generator could reasonably yield a shared index value and an inout element.) My preference, therefore, would be to structure the yields more like a parameter list, except hopefully without the unfortunate legacy paren/tuple representation. But we could also wait on generalizing the representation this way until we decide it's important; collection generators, after all, will only have one semantic yield.</div></div></div></blockquote><br class=""></div><div>Independent of the question of "do we want to represent their types in the AST", if the answer is "yes", this sounds like a reasonable design.</div><div><br class=""></div><div>-Joe</div><br class=""></body></html>