Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager via the forum messaging feature. When contacting the review manager directly, please keep the proposal link at the top of the message.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
+1, I needed this last week and was happy to have come across the pitch thread.
I'm glad to see this is a targeted proposal and I think what's been proposed deserves to exist in the Standard Library. It fills a real hole in the API for the result of an async operation and feels natural. I don't have experience in other languages, but did find that when copying the implementation from the pitch thread it worked exactly as I needed it to. No comment on the ancillary ideas to augment Result from the pitch thread.
I am firmly in favour of adding this interface. It's long overdue! I think the result of the body closure might need to be sending?
The Result type already effectively has all of these interfaces:
Proposed
Real
isSuccess
case .success
isFailure
case .failure
value
try? get() or case .success(let value)
error
case .failure(let error)
mapAsVoid()
map { _ in }
infallibleValue
get()
I recognize the ergonomics of all these alternatives aren't the same (in particular, pattern-matching with case isn't always usable in place of an expression) but a proposal to add some or all of these interfaces would need to firmly establish that they're a significant improvement.
No it doesn't have to. The closure is nonisolated(nonsending) and Result is conditionally Sendable on Success. This means that the value returned from body will be tied to the current isolation region. Similarly, the Result itself will be tied to the current isolation region. This means it cannot be sent across isolation domains.
+1 That looks great! I'm wondering if this would work with typed throw tho? Or would it need some explicit Result<Bool, SomeTypedError> to avoid loosing the error type?
That is why that API has not been accepted on Result yet; it feels like it might be better as a general improvement to enum pattern-matching.
At any rate, we don't need to discuss this further in this review. This API is a reasonable addition on its own, and it's okay for proposals to be narrow. Other additions should be separately pitched.
