-
-
Notifications
You must be signed in to change notification settings - Fork 735
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
Suggest unwrapping when passing Result(a, _)
instead of a
#3644
Comments
Sounds good! I'm not sure this is the right place for a code action though as most the time you don't want to use |
Could this apply the other way round too? For example: fn fallible(value: String) -> Result(Int, Nil) {
case value {
"1" -> 1
// ^ The compiler could suggest wrapping this in `Ok`
"2" -> 2
_ -> int.parse(value)
}
} Rust does this, for example |
I think that's a great idea but in that specific case there wouldn't be an error for that clause. |
Yes that's true, probably a bad example. Should I open a separate issue for that? |
For what, sorry? |
My suggestion above |
Sorry, I'm a bit confused. There's no type error on that line. How would it work? |
In a different case for example: pub fn wibble() -> Result(Int, Nil) {
10
//^ here for example
} Maybe that's not particularly useful though |
It would be nice if the compiler could suggest how to deal with a result when it's being used where the wrapped
Ok
value is expected instead. What I mean is:Have an error that looks like this:
error: Type mismatch ┌─ /Users/giacomocavalieri/Desktop/goto/src/goto.gleam:13:18 │ 13 │ parse_response(response) │ ^^^^^^^^ Expected type: Response(String) Found type: Result(Response(String), Dynamic) Hint: to get a value out of a `Result` you can pattern match on it case response { Ok(response) -> parse_response(response) Error(_) -> todo as "deal with error" }
We could also have a code action to apply this fix too.
The text was updated successfully, but these errors were encountered: