Dropping with arguments ("higher RAII")

[alonely0]

@SkiFire13

A natural formulation is to instead consider "implicitly droppable" as a capability, and make that a trait which gets implicitly implemented if HigherDrop is not implemented, then everything we currently have gets implicitly bounded by this new ImplicitDrop (like with Sized), and you can use ?ImplicitDrop + HigherDrop to allow it to be dropped with arguments. Adding a new implicit trait has always be considered a very extreme change though, so this might not be accepted. It also means that the entire ecosystem needs to be adapted for working with the lack of this capability, essentially creating viral ?ImplicitDrop + HigherDrop bounds on everything that can work with HigherDrop.

I agree with your conclusion, this is just not happening. This is the kind of thing that even though it's not a breaking change, it's so disruptive that we'd have to add it to the Rust 2.0 breakage whishlist.

@SkiFire13

you have to disallow converting HigherDrop types to trait objects, since they always assume the type to be droppable

• and since HigherDrop is not object safe you can't even have a HigherDrop trait object, which would not be entirely unreasonable

It's a fair trade-off.

@SkiFire13

you have to disallow any kind of control flow that would implicitly drop those types

We already have control-flow checks all around the compiler for lifetimes and other stuff, I'm sure we can (ab)use that to add checks to control-flow statements for HigherDrop types.

@SkiFire13

• this includes panics, which is particularly bad because you have to pessimistically assume a function may panic unless proven otherwise. For example just introduce a println in your function and now it may panic, see how this breaks @pitaj's proposal Rust Playground
• this also includes .await points, essentially either disallowing storing HigherDrop types in Futures, or propagating the HigherDrop requirement to the Future itself, and making it incompatible with most APIs we currently have.

In Rust, types are not expected to always be dropped, they must be safe to forget; this would include HigherDrop types. For panics, it might be sensible to add an uncallable function (like Drop::drop()) to HigherDrop that doesn't require arguments and takes by mutable reference. When it comes to .await points, correct me if I'm wrong, but when you drop a Future that has not been driven to completion, the data it holds is forgotten, not dropped (playground); it is up to manual Future implementations to do so. Thus, I don't get why .await points would be a problem.

[cg909]

@alonely0

When it comes to .await points, correct me if I'm wrong, but when you drop a Future that has not been driven to completion, the data it holds is forgotten, not dropped (playground ); it is up to manual Future implementations to do so. Thus, I don't get why .await points would be a problem.

The data of Futures is dropped. The async function in your playground example is just never polled, so it never executes and never constructs a Foo.

If you give it a Foo as an argument or hold the local variable over an await point and then only poll it once, then you'll see the "Dropped!" message.