You have a Result<Result<T, E>, E> and just want the inner Result<T, E>. Before Rust 1.89, that meant a clunky and_then(|r| r). Now there’s Result::flatten.
The problem: nested Results
Nested Results crop up naturally — call a function that returns Result, then map over the success with another fallible operation:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| fn parse_port(s: &str) -> Result<u16, String> {
s.parse::<u16>().map_err(|e| e.to_string())
}
fn validate_port(port: u16) -> Result<u16, String> {
if port >= 1024 {
Ok(port)
} else {
Err(format!("port {} is privileged", port))
}
}
let input = "8080";
let nested: Result<Result<u16, String>, String> =
parse_port(input).map(|p| validate_port(p));
// nested is Ok(Ok(8080)) — awkward to work with
|
You end up with Ok(Ok(8080)) when you really want Ok(8080).
The old workaround
The standard trick was and_then with an identity closure:
1
2
3
4
5
6
7
8
| # fn parse_port(s: &str) -> Result<u16, String> {
# s.parse::<u16>().map_err(|e| e.to_string())
# }
# fn validate_port(port: u16) -> Result<u16, String> {
# if port >= 1024 { Ok(port) } else { Err(format!("port {} is privileged", port)) }
# }
let flat = parse_port("8080").map(|p| validate_port(p)).and_then(|r| r);
assert_eq!(flat, Ok(8080));
|
It works, but .and_then(|r| r) is a puzzler if you haven’t seen the pattern before.
The fix: flatten
Stabilized in Rust 1.89, Result::flatten does exactly what you’d expect:
1
2
3
4
5
6
7
8
| # fn parse_port(s: &str) -> Result<u16, String> {
# s.parse::<u16>().map_err(|e| e.to_string())
# }
# fn validate_port(port: u16) -> Result<u16, String> {
# if port >= 1024 { Ok(port) } else { Err(format!("port {} is privileged", port)) }
# }
let result = parse_port("8080").map(|p| validate_port(p)).flatten();
assert_eq!(result, Ok(8080));
|
If the outer is Err, you get that Err. If the outer is Ok(Err(e)), you get Err(e). Only Ok(Ok(v)) becomes Ok(v).
Error propagation still works
Both layers must share the same error type. The flattening preserves whichever error came first:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| # fn parse_port(s: &str) -> Result<u16, String> {
# s.parse::<u16>().map_err(|e| e.to_string())
# }
# fn validate_port(port: u16) -> Result<u16, String> {
# if port >= 1024 { Ok(port) } else { Err(format!("port {} is privileged", port)) }
# }
// Outer error: parse fails
let r1 = parse_port("abc").map(|p| validate_port(p)).flatten();
assert!(r1.is_err());
// Inner error: parse succeeds, validation fails
let r2 = parse_port("80").map(|p| validate_port(p)).flatten();
assert_eq!(r2, Err("port 80 is privileged".to_string()));
// Both succeed
let r3 = parse_port("3000").map(|p| validate_port(p)).flatten();
assert_eq!(r3, Ok(3000));
|
When to use flatten vs and_then
If you’re writing .map(f).flatten(), you probably want .and_then(f) — it’s the same thing, one call shorter. flatten shines when you already have a nested Result and just need to collapse it — say, from a generic API, a deserialized value, or a collection of results mapped over a fallible function.