-
Notifications
You must be signed in to change notification settings - Fork 227
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using init(attempt:)
always produces Result
with AnyError
type
#255
Comments
Why are you using I'm curious why you'd do this and what benefit you're getting from it. |
So, Let's say I have an error like this:
And I have a function that throws:
Now let's say I want to do the mangling asynchronously. The only way I can think of writing that function now would be:
But with the proposed changes, it would be as easy as:
|
I think the way you'd normally do this with Result would be: func asyncMangle(_ string: String, completion: (Result<String, StringMangleError>) -> Void) {
let result = Result<String, AnyError>(attempt: { return try mangle(string) })
.mapError { StringMangleError($0.error) }
completion(result)
} It's not as concise as your example, but I'm not sure the indirection is worth the brevity in this case. |
Right. I guess that's a slightly more brief and functional way of writing that. However, I wasn't aiming so much for brevity but rather better inference, especially when it comes to errors. It might seem inconsequential from the provided example but in my current project I'm connecting many classes where each class has its own Currently, The following will currently not build: To achieve this, one needs to manually map Additionally, There is also currently no default inference for In my updated pull request, the following is true
|
Here's what I'd suggest:
In general, relying on inference isn't a great idea because Swift's type inference is limited. So I'm always hesitant to add an API that relies solely on inference. |
Closing this due to inactivity. |
I'm using
Result
in one of my projects but the thing that I would really appreciate is the ability to initialize aResult
with a throwing closure but with an arbitraryError
type. Eg.:where
WrapperError
can wrap otherError
s just likeAnyError
I've submitted a pull request here: #254
The text was updated successfully, but these errors were encountered: