Skip to content

Let Option derive #[must_use] #3906

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
dhardy wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Let Option derive #[must_use] #3906

dhardy wants to merge 3 commits into from
+66 −0

Conversation

@dhardy
Copy link
Contributor

@dhardy dhardy commented Jan 7, 2026 •
edited by rustbot
Loading

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

Rendered

@dhardy dhardy mentioned this pull request Jan 7, 2026
Merged
@ehuss ehuss added T-lang Relevant to the language team, which will review and decide on the RFC. T-libs-api Relevant to the library API team, which will review and decide on the RFC. labels Jan 7, 2026
@burdges
Copy link

burdges commented Jan 8, 2026

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

@Lokathor
Copy link
Contributor

Lokathor commented Jan 8, 2026

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
Copy link

dlight commented Jan 9, 2026

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
Copy link
Contributor Author

dhardy commented Jan 9, 2026

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
Copy link

dlight commented Jan 9, 2026

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

@kennytm
Copy link
Member

kennytm commented Jan 10, 2026

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
soqb reviewed Jan 14, 2026
View reviewed changes
text/0000-derive-must-use.md
# Guide-level explanation
[guide-level-explanation]: #guide-level-explanation

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

@soqb soqb Jan 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why "magically"?

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

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

"desugars"1 to

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

Footnotes

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

Copy link
Contributor Author

@dhardy dhardy Jan 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

dhardy commented Jan 15, 2026

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

1 more reviewer

@soqb soqb soqb left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

T-lang Relevant to the language team, which will review and decide on the RFC. T-libs-api Relevant to the library API team, which will review and decide on the RFC.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

7 participants

@dhardy @burdges @Lokathor @dlight @kennytm @soqb @ehuss