3 ms·
FWIW, for the process_item function, I've found writing it like: struct Item { value: u32, } fn process_item(input: Option<Item>) -> Option<Item>
by bluk 6y ago
FWIW, for the process_item function, I've found writing it like:
struct Item {
value: u32,
}
fn process_item(input: Option<Item>) -> Option<Item> {
input.map(|mut item| {
item.value += 3;
item
})
}
to be more "idiomatic" instead of doing the match on the Option. The methods like "unwrap_or...()", "map...()", "ok...()", "and_then()", etc. on Result/Option are very useful, if not a bit difficult to find the right one to use sometimes. Deeply nested match, "if let Some", etc. code becomes like a straight chain of method calls. In the end, I find that the Result/Option methods shorten code considerably and improve readability.
Also, instead of doing an unwrap() on optional values for assertion, sometimes I like:
let my_list = vec![1,2,3];
assert_eq!(Some(&my_list[0]), my_list.first());
Mostly just depends though since I don't care too much in tests.
- pirocks 6y agoIMO the issue here is with the question mark operator. If the Rust question mark operator was more like Kotlin's this wouldn't be an issue.
- fanf2 6y agoIt looks like Kotlin uses ? for nullable types, which isn’t really anything to do with Rust’s ? for short-cut error handling. https://kotlinlang.org/docs/reference/keyword-reference.html https://kotlinlang.org/docs/reference/keyword-reference.html You can also use ? with Option: fn process_item(input: Option<Item>) -> Option<Item> { let item = input?; Some(item + 3) }
- masklinn 6y agoI'm guessing they're referring the `?.` "safe calls" operator[0-] which essentially acts as a mix of `map` and `andThen` except only for property accesses and method calls, and can be combined with `let` for a more general map-like behaviour. [0] where many conceive of the operation as `?` being a modifying operator to `.`
- pirocks 6y agoIn kotlin your example would be: fun process_item(input: Item?) -> Item? { input?.plus(3) } This would have to be modified in rust to apply to both error and option types, as well as working on stuff other than the . operator, but I think it could be made to work. The main difference is that the ?. operator in kotlin works at the expression level, instead of the function level.
- arthurcolle 6y agoso I take it Option is an optional type in Rust? What am I supposed to do if I want to create a financial Option type in Rust? Gotta rename it? ;) Just kidding... unless... ?
- unrealhoang 6y agoYou can create and use Option without problem, your Option will be crate::Option, whereas Rust Option will be std::option::Option. std::option::Option<Option> works, yay.
- arthurcolle 6y agoI see, thanks. Really haven't ever used Rust for anything so didn't know exactly what namespacing was like. Sorry for the trite parent comment... :)
- baq 6y agoThe point of the article is that you won’t have that type: at the very least you’d have a PutOption and a CallOption.
- nemetroid 6y agoIf all the Option-handling that process_item() is doing is mapping None to None, is there any good reason for it to be Option-aware at all? fn process_item(input: Item) -> Item { input.value += 3; input } if let Some(item) = get_item().map(process_item) { println!("Success, item is {}", item); } fn get_item() -> Option<Item> { if /* success */ { let new_item = Item {}; return Some(new_item); } return None; }
- eecc 6y agoTo be honest the point of Option<T> isn’t just the pattern match but its underlying functor nature