search

rust-diplomat / diplomat

Experimental Rust tool for generating FFI definitions allowing many other languages to call Rust code
https://rust-diplomat.github.io/book/
Other
526 stars 49 forks source link

Get rid of `_destroy` symbols for non-opaque structs #130

Open CBenoit opened 2 years ago

CBenoit commented 2 years ago

Non-opaque structs should not have custom Drop implementation and are always passed by-copy. These should be trivially destructible. As such, *_destroy symbols for these custom types should not be emitted.

_Originally posted by @Manishearth in https://github.com/rust-diplomat/diplomat/pull/124#discussion_r795130198_

Manishearth commented 2 years ago

We should also probably force them to be Copy.

Ideally it would be nice to support non opaque structs containing opaque ones but that might be tricky?

Manishearth commented 2 years ago

We might be okay having non-Copy ones for returning but not for accepting by-move, so actually this might just be another validity check to install.

CBenoit commented 2 years ago

Ideally it would be nice to support non opaque structs containing opaque ones but that might be tricky?

I guess it's doable in C++ (by wrapping these with std::unique_ptr). In GC-based languages it will be pretty tricky (for idiomatic C# wrappers, I'm not even quite sure how to proceed with non-opaque structs containing non-opaque structs yet).

Manishearth commented 2 years ago

I guess it's doable in C++ (by wrapping these with std::unique_ptr). In GC-based languages it will be pretty tricky (for idiomatic C# wrappers, I'm not even quite sure how to proceed with non-opaque structs containing non-opaque structs yet).

Yeah precisely my concern.

Manishearth commented 2 years ago

I think this is where the distinction between inputs and outputs comes: we're fine with structs being returned that contain (mostly) anything, but it's trickier to accept structs doing so.

Basically, input types should not have:

but output types can have all of those except the first.