Add a MustUse trait to complement #[must_use]

[jonas-schievink]

This is intended to solve a couple of diagnostics issues, particularly around async/await (for example, #67387 and #71368).

Currently, this will expand #[must_use] on type definitions to MustUse impls, but due to coherence it is not yet possible to make #[must_use] on a trait expand to a blanket MustUse impl for all type implementing the trait.

I'm not quite sure what the solution for that would be, but it likely involves punching a hole in the coherence rules, similar to what's done for #[marker] traits, and possibly rejecting MustUse in trait bounds to guard against potential soundness issues introduced by that. I'm not sure if the trait system can give us all impls that could apply (so that the lint can collect all REASON strings), but even just getting an arbitrary impl should be enough to solve the diagnostics problem here.

Before I go ahead with that, I'd like to gather some feedback on the approach I've taken so far though.

[rust-highfive]

r? @ecstatic-morse

(rust_highfive has picked a reviewer for you, use r? to override)

[jonas-schievink]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 6c8c6bc06fe088345cc4bd00b4e5e56d97e31f48 with merge 88cbb409307e88eb10e428631ecaa67178e52435...

[bors]

☀️ Try build successful - checks-azure
Build commit: 88cbb409307e88eb10e428631ecaa67178e52435 (88cbb409307e88eb10e428631ecaa67178e52435)

[rust-timer]

Queued 88cbb409307e88eb10e428631ecaa67178e52435 with parent f05a524, future comparison URL.

[rust-timer]

Finished benchmarking try commit 88cbb409307e88eb10e428631ecaa67178e52435, comparison URL.

[nikomatsakis]

So, we discussed this once before in the meeting, and I was fairly skeptical of it then. I think I remain sort of skeptical, but I clearly see the advantages, as well, and I think the request is well-motivated, so I'm trying to keep an open mind. The alternatives I can come up with are basically extending #[must_use] with more options and maybe that's just worse.

Regardless, I think this sort of change also probably requires an RFC -- per our new process, that means we ought to see if there is a lang team liaison who wants to carry it through, I think.

I'm nominating for the upcoming triage meeting.

[nikomatsakis]

Ah, right, I also remember that this introduced an asymmetry, in that #[must_use] on a function can't be "reified" into the trait system.

[nikomatsakis]

(I haven't looked at the implementation details yet, I will say that this would be nicer given a chalk-like split :) but oh well.)

[nikomatsakis]

For completeness, I think the alternative would be to extend #[must_use] with something like #[must_use(conditional)], which says that, for some generic type Foo<P0..PN>, it is "must use" if any of P0..Pn are must-use. That would suffice for all known use cases (Pin, Option). We could even make it an error if there is more than one parameter.

That reminds me of another limitation of using the trait system for this. I guess if we make it a marker trait, it's ok, but otherwise you can't express the "any" in the statement above.

[Nemo157]

#[must_use(conditional)] would work for the newly mentioned case as well. But having something like impl<F: Future> MustUse for Foo<F> where F::Output: MustUse seems like it could potentially be useful somewhere.

[bors]

☔ The latest upstream changes (presumably #72120) made this pull request unmergeable. Please resolve the merge conflicts.

[nikomatsakis]

@Nemo157 that's an interesting example, yeah, although I'm not sure if it will really come up or not.

I guess I agree that it's better to (mildly) abuse the trait system than to invent a new specification language. I think my resistance to this idea of using a "magic trait" is weakening.

However, there is still the question of whether we want this extension to be opt-in or whether some kind of "opt-out". Opt-in would definitely be the more conservative route.

(I also tend to think an RFC is appropriate for this level of change, though I'm good with experimentation before that.)

[jonas-schievink]

Closing this as I don't really have enough time to go through the RFC process