Discarding return value, and ignoring return type

> he await method returns the underlying value, but you don't have to await. Perhaps there should be a special syntax for "do not await" -- which obviously just returns the Future itself -- and a linter or compiler warning could ensure that you have called one or the other. If the type is known at compile time to be a Future of some kind, the let _ syntax would give a compile-time warning, unless you explicitly call .do_not_await.

We already have a lint warning for dropping something that shouldn't be dropped, namely #[must_use], which is present on Futures. Clippy will warn you if you write an expression statement that implicitly drops a Future (and you can configure this lint to be deny-by-default if desired, so that it produces a hard compile error instead of a warning). The let _ syntax is the idiomatic way to silence that lint, so you're effectively proposing a second "no, I really mean it" syntax, to doubly silence the warning after it has already been silenced. I'm not sure why that would be any more effective than the existing lint is in isolation. There is, perhaps, some room for marginal improvement, since #[must_use] is quite liberal about what counts as a "use," and a Future-specific warning could be more exacting. But this seems to be well into diminishing returns relative to the increased language complexity.

If we think that #[must_use] is not sufficient, then I must concur with daroc: The logical next step is undroppable types, not another layer of "no, I really mean it" syntax. Undroppable types let us make hard assertions that you *must* dispose of an instance in the appropriate way.

We might also consider unforgettable (a/k/a unleakable) types, but I think it is much less common to accidentally leak an object than to accidentally drop an object (you either have to construct a refcounted cycle, or use an interface that "obviously" leaks, such as std::mem::forget or Box::leak). Those are only needed if you want to prohibit leaking objects as a safety invariant. In other words, you need them for cases where leaking an object could produce UB. That's pretty unusual, and the only obvious example I can think of is the original (now known to be unsound) API for std::thread::scope. But the new API does not need unleakables, and it was a fairly minor change, so this is not a great motivating use case for them.

There are three levels of badness here, not two. Discarding a return value in general should be OK, it could be informational (e.g. number of bytes copied). Ignoring Result is worse, it means that the caller doesn't care if the call was successful. I wouldn't do it in serious code, I would at least try to log the error. Ignoring Future is even worse. I cannot imagine why anyone would do, unless it's a test for the compiler, and nobody cares about the runtime behavior.