[Pitch] Result success and failure accessors

[Danny]

@corujautx

Perhaps this can evolve into Result also supporting the ?? operator

That won't happen, but I wish it would.

@corujautx

or having some sort of syntactic sugar to lift typed throw functions into Result types?

[Pitch] Result: Codable conformance and async "catching" init

Hi everyone, Here's a small pitch that I've drafted because of an usability issue with Result while working with some adopters. The short version is, I'd like to propose we: add Codable conformance to Result when its Success and Failure are both Codable add an async overload for init(catching:) using typed throws, in order to be able to convert an async operation into a well typed result The full proposal is here in a PR, please suggest any editorial changes on the PR and discuss the genera…

public extension Result where Success: ~Copyable {
  @inlinable init(catching body: () async throws(Failure) -> Success) async {
    do { self = .success(try await body()) }
    catch { self = .failure(error) }
  }
}

---

@corujautx

try? await request()
  .map(MyOtherType.self)
  .mapError(MyError.self)
  .get() ?? MyOtherType() 

That doesn't compile. It looks like

(try? MyOtherType(await request().get())) ?? .init()
(try? await request().get()).map(MyOtherType.init) ?? .init()

struct MyOtherType {
  init(_: MyType) { }
  init() { }
}

…which, like many other problems, would be best served with do-catch expressions:

do { MyOtherType(try await request()) }
catch { .init() }

func request() async throws(MyError) -> MyType {