Put glaring warnings and many capital letters in the docs of option::get() and option::unwrap().

[bblum]

I realised this when replying to @eholk on my blog: http://winningraceconditions.blogspot.com/2012/09/rust-0-index-and-conclusion.html?showComment=1348721405975#c9047445512681989061

Basically, I worry that novices who are familiar with null pointer checks but not familiar with the functional "option" idiom will start learning rust, then pop into the channel or go to their friends asking "How do I get the T out of an Option<T>??", and start using get() or unwrap() indiscriminately, when really they should be learning about match and how to properly handle the None case.

I think a big step here would be to write something like "WARNING: If you are not SURE that the optional value is not None, use a match statement instead and handle the None case explicitly!" in the documentation for these functions.

[brson]

This seems like a good use for typestate. option::get is usually paired with option::is_some or is_none, and that seems like a pretty reasonable restriction. Can we support just enough to do this in the most palatable way possible?

[brson]

I bet the system we had supported this pretty well :)

[bblum]

I remember myself using get and unwrap a lot and cringing every time I did - though looking back on it now, most of the cases could now be solved with match move to replace is_some and unwrap (others would be replaced with oneshot closures).

I dunno. I'm not sure it's worth more language features to track in the cases where you actually do need to be imperative about it.

[AngryLawyer]

I admit to using unwrap a lot - Rust's the first language that I've seen Option types in (the only other functional language I really know is Erlang). I've just done a grep through the code and seen how it's supposed to be, and now feel embarrassed.

Those who aren't exposed to the correct way of doing it are likely to do it wrong - I support the idea of making the documentation a bit more explicit about the correct way of getting things out of Options

[catamorphism]

Is there ever a legitimate reason to use is_some followed by get? I've seen code like this and wondered why people hated match expressions so much.

[eholk]

I think match versus is_some followed by get is just a personal style issue. The latter idiom is more familiar to imperative programmers, which I think many Rust programmers are or will be.

Still, using match doesn't quite solve the problem, as it's still really easy to add a None => fail clause. Error handling and recovery is hard. To me it's a similar issue to how C programmers rarely check the return value of functions that might return an error, and those that do often just terminate the program when an error is detected. I have a feeling all the language features in the world can't make programmers always write robust software.

[bblum]

While I think match is objectively better style than if is_some() - the only difference being that the compiler checks you in one of them..! - I am with eric on this.

Hence the suggestion to add docs rather than a small extra language feature (also perhaps rather than removing get() from the library altogether, which would be terrible).

[bblum]

@catamorphism I can't think of any. I used to use is_some followed by unwrap a lot (still visible in the task spawn code), but now match move provides that.

I do think get() should stay. People would just write it themselves.

[Dretch]

FWIW the if-based code is smaller and introduces only one new indentation level instead of two:

match x {
    Some(y) => {
        y.do_some_stuff(some_args, oh_its_quite_long);
    }
    None => {}
}

vs

if x.is_some() {
    x.get().do_some_stuff(some_args, oh_its_quite_long);
}

[burg]

In my experience, I would write .is_some() and .get() because of Dretch's example---if I'm already several matches deep and then match on Option, the extra indentation seems gratuitous and takes up a lot of source space despite being a very simple operation.

The pattern `if is.is_none() { /* do nothing; return */ } mimics the early returns that are common in C++ code like SpiderMonkey. In both cases, the intention is reduce indentation and the associated cognitive load.

[erickt]

@Dretch: option::iter is even shorter, and is my favorite way of dealing with this:

do x.iter |y| {
    y.do_some_stuff(some_args, oh_its_quite_long);
}

[bblum]

@erickt I think maybe what he meant was something like

if x.is_none() {
    return something_early;
}
if y.is_none() {
    return here_too;
}
if z.is_none() {
    return also_here;
}
this_would_otherwise_be_indented_three_times();

which is super "imperative". iter is definitely the functional idiom.

[brson]

I beefed up the docs a little in c83218d by adding Safety note sections to get, get_ref, and unwrap. I didn't make the language as ominous as requested in the OP though:

    In general, because this function may fail, its use is discouraged
    (calling `get` on `None` is akin to dereferencing a null pointer).
    Instead, prefer to use pattern matching and handle the `None`
    case explicitly. 

[bblum]

That looks super.