Future work on opaque result types

Development Compiler
,
2

I've been working on these, and addressed most of the remaining issues:

  • Structural opaque result types completed the implementation of structural opaque result types. There were scattered issues throughout the compiler.
  • Named opaque result types implemented the ASTScope name lookup changes @bdriscoll describes and a few of the other fixes needed so one can use named opaque result types so long as they don't add any additional requirements.
  • Generic environments and opaque types made it possible to use where clauses with named opaque result types, although the where clause has to go inside the angle brackets, e.g., func f() -> <T where T: Sequence> T { /* ... */ }.

My primary interest was in implementing SE-0328 "Structural opaque result types", which is now done on main. If someone were inspired to complete named opaque result types, here's my TODO list of things that would need to be done:

  • Check an opaque result type to make sure it mentions all of the named parameters somewhere, the same way we do for generic functions. For example, func f() -> <T> Int { } should complain about T not being mentioned in the result type, just like func g<T>() { } complains that T is not used anywhere in the function type.
  • Figure out what it means to name one of the generic parameters within the body of the function, or ban such uses entirely: func f() -> <T> T? { ... T ... }
  • Allow the function's where clause to specify requirements on the named opaque type parameters (along with other requirements), rather than the odd syntax that works now with the where inside brackets. The tricky part here is to sort out the requirements that apply to the caller vs. requirements that constraint the result type.

I'm not planning on working on any of these myself in the near term.

Doug

12 Likes