[bluk]

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.

[nemetroid]

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

[eecc]

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

[pirocks]

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.

[fanf2]

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)
  }

[masklinn]

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

[pirocks]

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.

[arthurcolle]

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

[baq]

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.

[unrealhoang]

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.

[arthurcolle]

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