Skip to content

Conversation

ktoso
Copy link
Contributor

@ktoso ktoso commented Mar 17, 2025

This is a proposal to add:

  • Codable conformance to Result when Failure and Success are Codable
  • async catching: init

The combination of those allows "catching" an async computation and have the result be Codable if the error also was.

ktoso and others added 2 commits March 17, 2025 21:00
Co-authored-by: YOCKOW <YOCKOW@users.noreply.github.com>
Co-authored-by: YOCKOW <YOCKOW@users.noreply.github.com>
@ktoso
Copy link
Contributor Author

ktoso commented Mar 17, 2025

Thanks for the fixups :)

@rjmccall rjmccall added the LSG Contains topics under the domain of the Language Steering Group label Mar 17, 2025
///
/// - Parameter body: A potentially throwing asynchronous closure to evaluate.
@_alwaysEmitIntoClient
public init(catching body: () async throws(Failure) -> Success) async {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes please!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1


## Motivation

The Result type is often used to bridge between async and not async contexts, and it may be useful to initialize a `Result` from the result of an async computation, to then pass it along to other non-async code without unwrapping it first. This is currently inconvenitnt because the `init(catching:)` initializer is missing an `async` overload.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The Result type is often used to bridge between async and not async contexts, and it may be useful to initialize a `Result` from the result of an async computation, to then pass it along to other non-async code without unwrapping it first. This is currently inconvenitnt because the `init(catching:)` initializer is missing an `async` overload.
The Result type is often used to bridge between async and not async contexts, and it may be useful to initialize a `Result` from the result of an async computation, to then pass it along to other non-async code without unwrapping it first. This is currently inconvenient because the `init(catching:)` initializer is missing an `async` overload.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
LSG Contains topics under the domain of the Language Steering Group
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants