[Pitch] Map Failure

Related Projects Swift Async Algorithms
7

I actually think mapError is a better name than mapFailure.

  • The name is consistent with existing declarations like Result.mapError and Combine.Publisher.mapError.
  • I think calling it mapFailure implies that map should actually be called mapSuccess (which would obviously be a bad name). The name mapError, on the other hand, implies that it's like the map method, but for when an error occurs, which I think is a better explanation.

I also think we should directly return AsyncMapFailureSequence rather than a some type. If we only return some AsyncSequence<Element, MappedError>, then the type system ignores the fact that AsyncMapFailureSequence is conditionally Sendable, which will make it more difficult to work with in async environments.

It might also be worth publicly exposing AsyncMapFailureSequence's base and transform properties so that people don't have to reimplement the type in order to access those properties. Access to those properties can be useful for conforming it to user-defined protocols and I think it's unlikely that this type's contents are ever going to change.

Additionally, I think it's worth considering that non-escapable types are currently being added to the language, and it might make sense to make AsyncMapFailureSequence a non-escapable type in order to avoid some restrictions of escaping closures. (I haven't been paying too much attention to those proposals, though, so I can't say for sure whether that would work or not.)

4 Likes