Add ZeroCopy marker and SchemaRead support #24
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We have simple zero-copy support for byte slices (
&'de [u8]), but we can provide enough compile time information to make this more robust.This PR adds a marker trait
ZeroCopythat is used to provide blanketSchemaReadimplementations for:&'de T where T: SchemaRead<'de> + ZeroCopy&'de [T] where T: SchemaRead<'de> + ZeroCopyPrimitive types that implement
ZeroCopyare:u8i8[T; N] where T: ZeroCopy#[derive(SchemaRead)]will implementZeroCopyon structs when itsTypeMetaisTypeMeta::Static { zero_copy: true }Vs
TypeMeta#16 introduced
TypeMetawhich also provides compile-timezero_copyinformation. So, why do we need this?TypeMetais geared for usage insideSchemaWriteandSchemaReadimplementations. Implementations can provide optimized compile-time branches depending on a type'sTypeMeta. Due to limitations in the type system,TypeMetais unusable for implementing something like aZeroCopymarker trait. In particular, constants in generics can't be used to constrain implementations. E.g., we cannotAnd as such we can't do anything similar to provide
impl<'de, T> SchemaRead<'de> for T where SchemaRead<'de> ...TypeMeta...Similarly, we could not use the
ZeroCopymarker trait to provide blanket implementations for built in types likeVec,Box, etc. because the compiler limits us to a single blanket implementation for each type, so we'd have to get into newtypes, which would yield a terrible API.So, there's a bit of duplication between where we advertise zero-copy, but the surface area is small since only
u8,i8and[T;N]are marked zero-copy and it's a relatively small amount of code to support. Users generally wont have to interface with any of these mechanics, so it's just a net win from a user-facing perspective.