Let Option derive #[must_use]

[dhardy]

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

Rendered

[burdges]

Is there some reason #[must_use] should not be a marker trait?

[Lokathor]

I would say that actually must_use is more a property of a particular function, not really of types, and sticking it on types is a shorthanded way to put it on a lot of functions "for free" cognitively. I'd say it's best if we, as an ecosystem, stick to having must_use on functions/methods rather than types.

[dlight]

I would say that actually must_use is more a property of a particular function, not really of types, and sticking it on types is a shorthanded way to put it on a lot of functions "for free" cognitively. I'd say it's best if we, as an ecosystem, stick to having must_use on functions/methods rather than types.

So #[must_use] could be a marker trait on the function's type where it is applied (each function has a unique type) and on each type it is applied. Then you add a blanked impl on functions whenever their output type impls the trait.

(it could be two traits, one for types you apply #[must_use] and another for functions, so that returning the function doesn't trigger it)

[dhardy]

I would say that actually must_use is more a property of a particular function, not really of types

Yes, but #[must_use] on types already has stable support (since 1.0 I think).

So #[must_use] could be a marker trait

Perhaps, but that would be quite a significant revision. Definitely out-of-scope for this RFC.

[dlight]

Agreed! For this RFC a trait is not necessary. If extending this feature to custom types is desired, a trait would be useful

[kennytm]

Note that it is already possible to mark a trait as #[must_use] (which is how rustc can warn about unused Future). It does not help this RFC though.

[soqb]

why "magically"?

why not permit #[must_use] on the parameters themselves, e.g.

pub struct Option<#[must_use] T> {
    Some(T),
    None,
}

"desugars"¹ to

impl<T: MustUse> MustUse for Option<T> {}

Footnotes

1. There will not necessarily be an actual MustUse trait in the implementation. ↩

[dhardy]

impl<T: MustUse> MustUse for Option {}

#[must_use] is not currently a trait. If you want to make an RFC for that, please go ahead. It may be a good idea, but it is an idea for another RFC, not this one.

Since #[must_use] is not currently a trait, we lack the language to describe derive behaviour, hence use of "magically" here.

Option<#[must_use] T>

Use of #[must_use] on parameters is novel syntax that I don't particularly like.

[dhardy]

Since there have been a number of suggestions about how to generalise this RFC, let me be clear: this RFC is extremely specific on purpose:

• This RFC affects only two std types in a way which should be compatible with any more general "must_use derive" mechanism
• It addresses what I see as the largest short-comings of #[must_use] without the complexity of a general "attribute derive mechanism" or turning #[must_use] into a trait