Skip to content
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.

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

#[must_use] silently does nothing on type aliases #26281

Closed
tamird opened this issue Jun 13, 2015 · 9 comments
Closed

#[must_use] silently does nothing on type aliases #26281

tamird opened this issue Jun 13, 2015 · 9 comments
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@tamird
Copy link
Contributor

tamird commented Jun 13, 2015

There are at least two problems with #[must_use]:

  • it doesn't work on type aliases at all.
  • for methods that return a type containing a #[must_use] type, no warning is issued if the #[must_use] value is immediately discarded by destructuring assignment at the caller.

http://is.gd/TEG45t


Edit: the consensus is that #[must_use] should not be usable on type aliases, but it should not just silently fail. The behaviour with destructing assignment is intentional.

@Thiez
Copy link
Contributor

Thiez commented Jun 13, 2015

Performing let _ = yields_must_use(); already silences the #[must_use] warning, surely it would not make sense for let (x, _) = yields_tuple_of_u8_and_must_use(); to give a warning; it is doing the exact same thing as assigning a #[must_use] to _.

As for the type aliases, they always have the exact same behaviour as their original type. If you want different behaviour you must use a newtype. It would be inconsistent to make an exception for #[must_use].

@tamird
Copy link
Contributor Author

tamird commented Jun 13, 2015

Alright, let's forget about the type alias case.

I still feel that the tuple cast (or any other destructuring assignment) presents a hole in the semantics of #[must_use].

@nagisa
Copy link
Member

nagisa commented Jun 14, 2015

I’m on the same page as @Thiez.

@steveklabnik steveklabnik added the A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. label Jun 15, 2015
@Mark-Simulacrum
Copy link
Member

The type alias problem here appears to have been discussed and decided on as intentional. The tuple problem is covered by #26291, as far as I can tell, or should be added to that issue and this issue closed.

@Mark-Simulacrum
Copy link
Member

Just ran into #[must_use] on a type alias silently doing nothing. I understand why it doesn't make sense for it to work, but I do expect some form of warning. Should I open another issue about that?

@Mark-Simulacrum
Copy link
Member

Rebranding this as #[must_use] silently does nothing on type aliases.

@Mark-Simulacrum Mark-Simulacrum changed the title #[must_use] holes #[must_use] does nothing on type aliases May 16, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 22, 2017
@zackmdavis
Copy link
Member

but I do expect some form of warning

Related/likely-prerequisite: #14407.

@varkor varkor changed the title #[must_use] does nothing on type aliases #[must_use] silently does nothing on type aliases Jun 29, 2019
@KamilaBorowska
Copy link
Contributor

KamilaBorowska commented Jan 14, 2022

I don't think it would be necessarily inconsistent to make #[must_use] work for types because unlike most attributes, #[must_use] doesn't affect code generation. Other attributes that don't affect code generation - allow, warn, deny, forbid, deprecated and doc work fine for type statements.

@jieyouxu
Copy link
Member

As of stable 1.76.0, rustc emits the following warning:

warning: `#[must_use]` has no effect when applied to a type alias
 --> src/main.rs:4:1
  |
4 | #[must_use]
  | ^^^^^^^^^^^
  |
  = note: `#[warn(unused_attributes)]` on by default

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

8 participants