Problems with destroy ergonomics when using it from Drop

[LaylBongers]

Currently, when destroying any backend structure explicitly, such as a buffer, you need to pass it by value.

device.destroy_buffer(vertex_buffer);

These semantics make sense in principle, but in practice it makes it hard to write simple wrappers that RAII wrap around these types.

impl Drop for Mesh {
    fn drop(&self) {
        let device = &self.common.device;
        unsafe { device.destroy_buffer(self.vertex_buffer); } // < can't move out of reference error
    }
}

A solution is to wrap all these types in Option, but this quickly becomes very cumbersome just for this one specific use. Since these functions are already unsafe, why not just allow them to take &mut?

[zakarumych]

I use ManuallyDrop wrapper

[LaylBongers]

How can ManuallyDrop be used to solve this problem?

[kvark]

These semantics make sense in principle, but in practice it makes it hard to write simple wrappers that RAII wrap around these types.

I have many thoughts on the issue, but no solution:

1. Did you consider not using RAII for graphics stuff?
2. I'd really like to see drop accepting things by value. This has been my pet peeve with Rust since the beginning. I don't care how special should the compiler glue be, moving out of life just makes so much more sense as borrowing.
3. https://github.com/gfx-rs/wgpu will have droppable objects, but it's a slightly higher level API.

[LaylBongers]

The more specific use case I'm running into is, for example, putting a rendering System in a specs World. The rendering system itself owns some graphics resources, but there's no way to entirely get back ownership to the system, or even access it again.

There may be some better ways to solve this issue, perhaps this is enough of a common use case that it would make sense to have an example on it to both inform gfx and specs' design?

[kvark]

A gfx-hal example with specs would indeed be helpful. Although, again, we expect most gfx-rs users to just move to wgpu-rs instead.

…

On Oct 27, 2018, at 12:19, Layl ***@***.***> wrote: The more specific use case I'm running into is, for example, putting a rendering System in a specs World. The rendering system itself owns some graphics resources, but there's no way to entirely get back ownership to the system, or even access it again. There may be some better ways to solve this issue, perhaps this is enough of a common use case that it would make sense to have an example on it to both inform gfx and specs' design? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[LaylBongers]

Personally, I really enjoy working at a low level like gfx-hal provides, while still having the benefits of easier cross-platform-native porting. This specific API issue is the main one I ran into when using gfx-hal in this way. Is there any problem with changing the API to use &mut instead? To compare it to other libraries, when working with Ash you would pass a Copy handle to the destroy method, and as a result it doesn't have this issue.

Alternatively, a workaround would be useful.

[zakarumych]

@LaylConway ManuallyDrop works in similar way as Option does in this situation. But it doesn't consume additional memory.
Basically in Drop implementation you just std::ptr::read its content and destroy.

[kvark]

@LaylConway @omni-viral please have a look at #2457 RFC

[shepmaster]

This question also came up on Stack Overflow. One answer there shows usage of Option as well as ManuallyDrop.

[Lokathor]

Using ManuallyDrop is probably the most ergonomic answer here. The Deref and DerefMut impl means and you don't have to think about stepping through the wrapping layer during all the rest of the code.

Using the "read and destroy" technique that omni-viral alluded to would look something like this:

use core::ptr::read;
self.device.destroy_render_pass(ManuallyDrop::into_inner(read(&mut self.render_pass)));