<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body 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 class=""><br class=""></div><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 class=""><br class=""></div><div class="">John.</div></body></html>