option: rename unwrap to get or remove get_ref in favour of as_ref().unwrap()

[thestinger]

There are already nearly identical methods named get_ref() and get_mut_ref() and std::hashmap names the equivalent method get. This method doesn't always move, it's just a normal by-value method, so it should follow the same convention as other get-or-fail methods. If it used the shorter naming, replacing get_mut_ref() with as_mut().get() would only add a character.

[alexcrichton]

I was under the impression that we were going to rename get_mut_ref to get_mut to align with as_{ref,mut}?

I also believe that the reason for leaving these two methods instead of making them composable was because they're likely very common patterns.

[thestinger]

Nominated for library backwards compatibility tag.

[nikomatsakis]

+1 for unwrap() => get()

[catamorphism]

If we rename, other types (like arcs) should be consistent.

1.0, backwards-compat

[pcwalton]

This is fine, but please let's stop changing this. This needs to be the last change and then this method is frozen and changing it is off the table.

[mletterle]

I vote for get(), I think it's more intuitive, especially with get_or() and any other variations.

[Kimundi]

1+ for get(), ever since @thestinger added the Option by-ref adapters this became the most fitting name.

[glaebhoerl]

One thing that's not clear to me: among Haskellers, using fromJust is considered nearly evil, and is avoided whenever possible, while among the Rustic it's so common that making it convenient is a significant consideration. Why is that?

[thestinger]

It's better to have a reusable evil method with a concise name than the current situation of many functions preferring to fail than return an Option because people find them too inconvenient. In most application code, not every error case is going to be handled. In library code, you definitely want to expose the ability to handle any error cases, without making common application code painful.

[huonw]

It sounds like it might be worth going through the stdlib and converting fail!()-ing constructors (and other functions) to ones returning Options or Results where reasonable, since the stdlib will set the tone for other libraries.

I agree with @glehel that Rust seems to be far too free with using .get()/.unwrap()... even .expect("<some useful message>") is better since it makes it (1) obvious that the author has thought a little about the failing case, and (2) gives a slightly useful error message, rather than just called Option::unwrap()on aNone value, which is pathetically useless, and requires diving into GDB to work out exactly where it happened.

As a point against this in Rust, we don't have the functors/applicatives/do-sugar that Haskell has that makes working with these nicer.

[Kimundi]

Also, we very often use use Option in situations where you know it's not going to be a None for the value you're calling the function with.

For example, something like let v: uint = from_str("123").unwrap() will never fail, as will iterative constructs like this:

if opt.is_some() {
    // ...
    let x = opt.unwrap();
    // ...
}

Mutable options also necessitate a lot of wrapping and unwrapping of values, as those cases are basically one-element containers.

[nikomatsakis]

cc #13159