Type-annotate and simplify documentation of Option::unwrap_or_default

[gimbling-away]

Part of #100054

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[rust-highfive]

r? @joshtriplett

(rust-highfive has picked a reviewer for you, use r? to override)

[joshtriplett]

This is certainly an improvement, and I'm going to go ahead and merge it as such:

@bors r+ rollup

However, this also doesn't seem like a very good documentation example, given that Result::unwrap_or_default exists and would be a better choice in this case. (Your change is an improvement to the example, and the nature of the example isn't something your commit changes; this just called attention to it.)

Perhaps a better example would use an array and slice::get, or something like Iterator::min?

[bors]

📌 Commit 4411d5f has been approved by joshtriplett

It is now in the queue for this repository.

[GuillaumeGomez]

Wouldn't it be better instead to not need type annotation? For example:

let x: Option<u32> = None;
let y: Option<u32> = Some(12);

assert_eq!(x.unwrap_or_default(), 0);
assert_eq!(12.unwrap_or_default(), 12);

I find the usage of Result unneeded and it adds complexity for no benefit.

EDIT: After a refresh I saw @joshtriplett's comment and I guess we both agree. 😆

[gimbling-away]

We can always add a better example later on =)

[GuillaumeGomez]

Well, we could have done it correctly directly but it doesn't matter much. I'll just send a PR once this one is merged.

[gimbling-away]

I mean, I can probably extend this PR, right now :y

[GuillaumeGomez]

It's about to get merged so better not. :)

[GuillaumeGomez]

@gimbles Do you want to send a PR with the code I suggested instead?

[GuillaumeGomez]

I opened #102283 as a follow-up.