Skip to content

#[must_use] on associated function definition when trait declaration does not have it should still trigger warning when calling function concretely #48486

New issue

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

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

Already on GitHub? # to your account

Open
Havvy opened this issue Feb 23, 2018 · 2 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Havvy
Copy link
Contributor

Havvy commented Feb 23, 2018

I expect the following code (Playpen) to emit a warning on the last line of main that the result of s.the_must_use_fn() must be used.

fn main () {
    let s = Struct;
    s.the_must_use_fn();
}

trait Trait {
    fn the_must_use_fn(&self) -> String;
}

struct Struct;

impl Trait for Struct {
    #[must_use]
    fn the_must_use_fn(&self) -> String { "".to_string() }
}

Ref #43302 as the tracking issue for this feature.

@zackmdavis
Copy link
Member

This is expected (or at least, known) behavior; the #[must_use] attribute needs to go on the function signature in the trait definition, not the implementation. I argue that the current behavior makes sense: the semantics of a trait method should be the same across implementations. We should document this better, though—thanks for starting on that!

@Havvy
Copy link
Contributor Author

Havvy commented Feb 23, 2018

Then there should be a warning when #[must_use] is on a trait method.

But while it is known behavior, I didn't expect it. I expect that concretely calling a trait method should work the same as concretely calling an inherent method. Of course, when called generically, it should only look at the trait declaration.

@pietroalbini pietroalbini added C-enhancement Category: An issue proposing an enhancement or a PR with one. A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 27, 2018
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants