Adds `must_not_await_lint` RFC by bIgBV · Pull Request #3014 · rust-lang/rfcs ·...

comex commented on Nov 10

Editorial: The title of this issue shouldn't say #[must_not_await_lint]. The RFC name is must_not_await_lint, the attribute is #[must_not_await].

Bikeshed: Decorating a type with "must not await" sounds like it's forbidding you from awaiting values of that type – not from capturing values of that type while awaiting some unrelated object. However, I can't think of a better name that isn't considerably more verbose.

Bikeshed: #[must_not_suspend]?

LucioFranco commented on Nov 19

@bovinebuddha I personally think that is more confusing, since most users interact with await and not the concept of suspending a task. We originally had must_not_yield and that was too low level imo.

erickt commented 29 days ago

bikeshed: I could see a feature like this being useful in generators and coroutines, since we also wouldn't want to hold mutexes across those yield points as well. So going for more generic language like #[must_not_suspend] would help avoid churn down the road.

kw-fn commented 28 days ago

#[must_not_halt]

bIgBV commented 24 days ago

@erickt that's a fair point. We did not consider extending the use of this attribute to be used for generators in the future, but I can see how it would be possible. I think #[must_not_suspend] is a good name for the attribute considering this.

LucioFranco commented 22 days ago

@erickt My concern about going a bit lower level with the generator based name is that it has some sort of disconnect from async/await. We may want to just consider to add another version when we finally stabilize generators?

nikomatsakis commented 18 days ago •

We discussed this in the @rust-lang/lang meeting today and came to the conclusion that we would like to move this forward to the implementation stage, modulo whatever bikeshedding makes sense for the name.

@rfcbot fcp merge

rfcbot commented 18 days ago •

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

joshtriplett commented 11 days ago

One thing I'd like to see added to the open questions and alternatives sections: would it suffice to only support this on functions, and not on types? With #[must_use], a great deal of complexity and potential future surface area arises around what happens if you embed that type inside some other type, and whether #[must_use] still applies then. The "Unresolved questions" section mentions solving this problem for #[must_not_await] as well, but another alternative would be avoiding this problem entirely by only applying this to function return values.

I don't know if this is a good idea, or if it'd result in having to add far more annotations. I think it's worth discussing the tradeoff in the RFC.

tmandry commented 8 days ago

rust-lang/wg-async-foundations#19 is a related (but separate) idea that folks should be aware of. This is another attribute that would warn when certain functions are called in an async context. It might be worth mentioning this as a future direction in the RFC.

bIgBV commented 8 days ago

@tmandry I think we should mention it in the RFC as a way to talk about other work in this area, but aren't these two separate concerns?

tmandry commented 8 days ago

Yes, they're separate, but conceptually they are related. I just think the RFC should mention it as you say.

I don't mean to imply that it would be a future direction in the sense that it would build on this RFC, but that it's simply another thing we might consider doing in the future.

joshtriplett commented 2 days ago

I'm still interested in seeing the RFC discuss whether we could get the same benefits with only attributes on functions, and not attributes on types, to entirely sidestep the issues must_use has of how or if to propagate this through nested types.

bIgBV commented 2 days ago

@joshtriplett That's a good point, though I might be missing something, but if we limit the attribute only to functions, wouldn't that mean that types constructed from structs/enums that should be #[must_not_await] might not be, correct?

// Should be #[must_not_await]
struct MyType(usize);

async fn main() -> Box<dyn std::error::Error> {
    let foo = MyType(42);
    bar().await;
    println!("{}", foo);
}

async fn bar() -> usize {
    99
}

In this example, MyType should ideally be #[must_not_await] but limiting the attribute to functions would prevent that.

joshtriplett commented 23 hours ago

@bIgBV That's the open question: are there concrete cases people want to use #[must_not_await] for where the value being awaited is not just a value returned by a function? (For instance, "guard" types seem likely to be returned by functions rather than constructed directly.)

That said, the more I think about it, the more this fundamentally does seem like a property of a type; at the await point, the compiler is holding a value across that await point, and it's more natural to associate the need for a lint with the type of that value than origin-tracking of where that value came from.

@rfcbot reviewed