SE-0346: Lightweight same-type requirements for primary associated types

[hborla (Holly Borla)]

@swhitty

Regarding @rethrows — I don’t think it has been explicitly addressed in the proposal or this thread and it probably needs to be.

This proposal does not provide a solution for writing effects constraints for rethrowing protocols. This is a general problem with both opaque result types and generic code that wants to generalize over an effect, independent of primary associated types. John's write up here outlines the limitations on the current form of rethrows and possible language solutions to lift those limitations:

Precise error typing in Swift

Introduction When error handling was added to Swift in 2015, it intentionally did not allow the expression of precise error types: either a function cannot throw, or it can throw any Error. The error-handling rationale I wrote, which uses an awful lot of words to describe most aspects of the design, gives this one pretty short shrift: There are many kinds of error. It's important to be able to recognize and respond to specific error causes programmatically. Swift should support easy pattern-m…

In my opinion, this problem should be solved as part of the rethrowing protocols proposal (or possibly subsumed by a "typed throws" proposal), which hasn't gone through a formal review yet. Depending on the language design for generalizing rethrowing protocols, effects constraints could either compose with opaque result types via keyword, e.g. (strawman!) some throws(ErrorType) AsyncSequence<Element> or via normal same-type constraints. For example, a precise error associated type could become a primary associated type of AsyncSequence, e.g some AsyncSequence<Element, MyError>. If the latter is the solution, we might want a way to default the constraint to Never, similar to how not writing throws means the default is non throwing.

So, the important thing to figure out for this proposal is whether the current design leaves room for these future language features. I can think of a few implications:

• This proposal does not preclude the ability to add an effects specifier to opaque result types via keyword, e.g. some throws P.
• If the model for rethrowing protocols transitions to use an associated type, we probably want to leave room for defaulting the constraint on a primary associated type. To me, that suggests that the proposal should remove the ability to add a default type witness for a primary associated type in angle brackets via =. If effects constraints are deemed not common enough to warrant lifting the error associated type to be "primary", perhaps that's motivation for generalized opaque result type constraints, which is also not precluded by the proposed design.
• Currently, the default effect for code that's generic over a rethrowing protocol conformance is throws. If we want the syntax some AsyncSequence<Element> to default to non-throwing, we should not adopt primary associated types for AsyncSequence until there is a way to express that default. This proposal does not include adopting primary associated types in the standard library (that will be a separate proposal and discussion) so this proposal doesn't preclude that either.