zerocopy support

[tbu-]

I'm already using Google's zerocopy in my crate and want to start using object. Would a PR adding support for zerocopy bee accepted? Theoretically, the whole pod module could also be replaced by it.

[bjorn3]

The zerocopy crate can't be used as dependency of libstd as it doesn't have the rustc-dep-of-std hack. Libstd depends on object through the backtrace crate. As any zerocopy integration has to be optional.

[tbu-]

Some information on the rustc-dep-of-std hack, since I didn't know about it before: rust-lang/wg-cargo-std-aware#51.

[philipc]

The pod module is small, does exactly what this crate needs, and can't be replaced (as bjorn3 says).

Can you give an example of what adding zerocopy support would enable you to do that you can't easily do without it? Can you give a reason for choosing zerocopy instead of another option (bytemuck is the most common alternative)?

I have looked at both zerocopy and bytemuck in the past and my impression was they don't gain us anything. In particular, we can't use their derive support because they don't support type parameters (needed for endianness).

[tbu-]

we can't use their derive support because they don't support type parameters (needed for endianness).

Ah, that sucks. :(

Can you give an example of what adding zerocopy support would enable you to do that you can't easily do without it?

Using the crate's structs in my own zero-copy-derived structs, with safety guaranteed by zerocopy.

Can you give a reason for choosing zerocopy instead of another option (bytemuck is the most common alternative)?

I wasn't aware of bytemuck, interesting. It doesn't seem to have endianness support though/

[philipc]

Using the crate's structs in my own zero-copy-derived structs, with safety guaranteed by zerocopy.

Ok, but the safety can't be guaranteed because the derive doesn't support this crate's structs (unless it has changed since I last looked). So is there still any value to this?

I wasn't aware of bytemuck, interesting. It doesn't seem to have endianness support though

We would still need to define our own endianness types, whether we use zerocopy or bytemuck, since zerocopy doesn't have an equivalent of Endianness.

[tbu-]

Ok, but the safety can't be guaranteed because the derive doesn't support this crate's structs (unless it has changed since I last looked). So is there still any value to this?

The safety can be guaranteed for my own crate when I use zerocopy, since I don't use generic endianness there.

It seems that zerocopy only supports generic endianness on #[repr(packed)] structs, but it does work there:

use zerocopy::ByteOrder;
use zerocopy::U64;
use zerocopy_derive::AsBytes;

#[derive(AsBytes)]
#[repr(packed)]
struct Struct<O: ByteOrder> {
    integer: U64<O>,
}

We would still need to define our own endianness types, whether we use zerocopy or bytemuck, since zerocopy doesn't have an equivalent of Endianness.

Ah, the Endianness type is some kind of run-time dynamic endianness?

[philipc]

The safety can be guaranteed for my own crate when I use zerocopy, since I don't use generic endianness there.

So you're not using this crate's structs in your own zero-copy-derived structs then. To be clear, it's going to be a high bar to add support here. You'll need to give a code example of what it allows you to do. Simply avoiding importing another trait in your crate isn't enough.

Ah, the Endianness type is some kind of run-time dynamic endianness?

Yes.

[tbu-]

The safety can be guaranteed for my own crate when I use zerocopy, since I don't use generic endianness there.

So you're not using this crate's structs in your own zero-copy-derived structs then.

Yes, I currently can't derive zerocopy's traits because this crate doesn't implement them on its types. This is basically the reason for this feature request.

You'll need to give a code example of what it allows you to do. Simply avoiding importing another trait in your crate isn't enough.

Makes sense. Since I don't have a finished crate, I'll close this feature request. I'll come back if I ever finish this project.

[bjorn3]

Also object can't make use of the zerocopy derive macros anyway as libstd can't (directly or indirectly) depend on any proc macro without breaking cross compilation support.