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.
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 could 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. The basic structure of an accessor coroutine type is: - It can still have arbitrary parameters as normal (because of subscripts). - The result type is always (). - There is one yield. - The yield can be inout, owned, or shared. 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. John.
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
