To be fair, if reconnectAndGetConn returns a compatible error type, this would presumably allow us to try to recover, right?
let? Ok(r) = switch getConn() {
| Ok(x) => Ok(x)
| Error(ErrorA) =>
reconnectAndGetConn() // hypothetical recover
| Error(ErrorB) =>
Error(ErrorB) // not possible?
}
Good point, that’d definitely work.
I’m all for this proposal
At the moment switch case verbosity is so bad my Rust implementation has the same amount of lines as Rescript.
let? Makes a lot of sense, the ? Shows the None is quick returned, and the Some shows what you are looking for.
And competes with Gleam’s use var <- try(fn())
Dart and Rust also have eager error handling with ?
GoLang’s 3lines of if err != nil after every functionality makes me nauseous
Playing devils advocate: would this work? let? Error(err) = fn() as an early happy return.
We could definitely support let? Error(err) = ... and let None = ... if that adds any value. Just a matter of swapping what’s emitted for the continue vs return case.
In let? Ok(user) = fetchUser()
If you see let? as testing if fetchUser() returns an Ok then yes I’d expect the reverse to be possible too, this also aligns to what we are used to in switch pattern matching.
@lil5 I updated the PR supporting let? Error(e) = ... and let? None = .... PoC of let? by zth · Pull Request #7582 · rescript-lang/rescript · GitHub
Looks good to me! Ship it! 
Happy to say this was just merged under the new concept of “experimental features” (that you will be able to turn on/off in rescript.json) and will be in the next beta that’ll be released this week 