Let Option and Box derive #[must_use] from their generic parameter T.

Motivation

If we write:

#[must_use]
struct Redraw;

fn do_thing() -> Option<Redraw> {
    // Do some thing which requires a redraw...
    Some(Redraw)
}

then do_thing should be #[must_use], and while we can apply the #[must_use] attribute to the function do_thing, we shouldn't have to (remember to do so).

Guide-level explanation

The Option and Box types will "magically" have the #[must_use] attribute if and only if their generic parameter T does.

Reference-level explanation

This will be an internal detail of the standard library. It may use another special attribute like #[derive_must_use_from(T)], but for the purposes of this RFC, the derive_must_use_from attribute may remain unstable forever.

Drawbacks

I see no drawbacks besides the small amount of complexity involved.

Rationale and alternatives

The only obvious (non-empty) alternative is to add (and stabilise) a new #[derive_must_use_from(T)] attribute and apply this to Option<T> (and other types).

This would not be a strict alternative in that nothing prevents this from being done later.

Prior art

RFC #3737 is vaguely related (only in that it also pertains to #[must_use]).

#[must_use] is already tracked through tuples (example), though strictly speaking this does not apply #[must_use] to the tuple type.

Unresolved questions

Future possibilities

Possibly a few other standard library types would benefit from this derivation of #[must_use]:

Box<T> can do so (included in this RFC, though motivation is weaker)
RefCell<T> and Mutex<T> could do so but it is unlikely of any use
Rc<T>, Arc<T> and various reference types should not since they do/may not have exclusive ownership of the value
Vec<T> and other containers could do so

Let Option derive #[must_use]