Open joshlf opened 2 years ago
Would it be possible to have a special case if the type parameter has a bound on ByteOrder
and only on ByteOrder
by checking all implementations of ByteOrder
? ByteOrder
is a sealed trait, so all implementations of it are known. This would make it much easier to write code that handles file formats that can be both little and big endian.
I'm not sure what the relevance of ByteOrder
is here? The byteorder-aware types in the byteorder module implement AsBytes
, but a type can satisfy the rules of AsBytes
even if its type parameters do not implement ByteOrder
. What's the connection you're getting at?
I did like to have types like
#[derive(FromBytes)]
struct Foo<B: ByteOrder> {
a: U32<B>,
b: U32<B>,
}
to work with both little endian and big endian using the same type definition. However the restriction of not having any type parameters when deriving FromBytes prevents this. I thought it did be easier to allow FromBytes just for type parameters bound by ByteOrder than implementing the general case.
That code should work fine. It's just #[derive(AsBytes)]
that doesn't currently support generics (actually, on ToT, it supports generics on a struct so long as that struct is also #[repr(transparent)]
or #[repr(packed)]
).
(actually, on ToT, it supports generics on a struct so long as that struct is also #[repr(transparent)] or #[repr(packed)]).
I see. Adding #[repr(packed)]
would work for my case.
I wonder if single field #[repr(C)]
generic structs can be treated the same way as #[repr(transparent)]
for this purpose?
They could, but I'm not sure what the point would be. If you're considering adding #[derive(AsBytes)]
to such a type, then:
#[repr(C)]
with #[repr(transparent)]
and not change the behavior#[derive(AsBytes)]
thanks to #[repr(transparent)]
@joshlf I'm interested in working on this. Would you be interested in seeing an exploration of any of the following?
generic_const_exprs
.Thanks for your interest! The type-level representation of size and alignment is what we'd consider. I'll warn you that the design space there is large and there are lots of thorns, and since any traits introduced will be part of our public API, we'll be very nitpicky about the exact design. That said, it would be great to have some experimentation with this at a minimum, and if you're willing to put up with our nitpickiness, then a full implementation would obviously be very welcome!
For inspiration, see: https://github.com/google/zerocopy/issues/1316#issuecomment-2120930160 (although I haven't looked closely at those examples, and I'm not sure whether they address all of our needs).
Migrated from https://fxbug.dev/100235
In order to accomplish this, we need to be able to emit an impl which is bounded by a const expr, which requires the unstable feature
generic_const_exprs
. This issue is blocked until that feature is stabilized.