Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



If 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;
  }


To be honest the point of Option<T> isn’t just the pattern match but its underlying functor nature


IMO 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.


It 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

You can also use ? with Option:

  fn process_item(input: Option<Item>) -> Option<Item> {
      let item = input?;
      Some(item + 3)
  }


I'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 `.`


In 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.


so 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... ?


The point of the article is that you won’t have that type: at the very least you’d have a PutOption and a CallOption.


You 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.


I 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... :)




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: