rust-lang / book

The Rust Programming Language

Home Page:https://doc.rust-lang.org/book/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Chapter 6.2 - Context or alternative examples to illustrate `None` usage

julix-unity opened this issue · comments

URL to the section(s) of the book with this problem:
https://doc.rust-lang.org/book/ch06-02-match.html#matching-with-optiont

Description of the problem:
The plus_one with None example feels abstract, it's not clear why the match is needed there at all, since the function works fine without:

fn plus_one(x: i32) -> i32 {
    x + 1
}

The previous example with the coins (even sorting by state) felt so applied that the contrast to this much more artificial example is jarring.

[aside] Additional context: My brain might be JavaScript poisoned where type coercion is rampant. Therefor if I called a plus_one with no arguments I'd expect it to either to return "one more than nothing "(1) as a fallback or better to error explicitly complaining about lack of valid arguments - probably same with null. [/aside]

Suggested fix:
I don't have a great solution, since I don't really know when None happens in Rust.

Could we provide context for how/why plus_one might receive a value that is currently invalid or absent for some reason. Maybe it's already a natural example and it just feels arbitrary to me since I don't understand how x became None (other than for demo purposes).

Or if it isn't, could we use a different example where None would happen naturally? ChatGPT suggested optional configuration settings, where a function might need to handle an Option to account for both specified and unspecified (or default) settings (it claimed that was a common case across domains, and I guess it reminds me of user input from forms with "prefer not to say" as an option, so if there's a Rust equivalent perhaps it's good).

Intention:
I'm hoping that by raising what caused friction for me perhaps we can smooth transition into Rust for folks that are new or like me come from dynamic programming languages like JS.

Thanks for opening this! I can understand what you mean about the shift between the very real-world-feeling example of the coins to the more abstract plus_one. I am not sure if we will end up significantly changing this, but for reference, the way to think about it coming from JS or similar is: all the places where you can imagine having some value be undefined or null is a place where you would have an Option in Rust instead. That could be user-entered data, data from an API which is allowed to be missing, etc. Part of the goal here, I think, is to keep the sample code simple enough that it does not require introducing any other “support” code around it, but I think we might be able to finagle a small additional bit of text to motivate it if we think it is a significant enough stumbling block. At a minimum, we will chat and think on it. Thanks for the feedback!