-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MaxSize as a const fn #179
base: main
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for cute-starship-2d9c9b canceled.
|
1 | ||
} else { | ||
// CEIL(variants / 7) | ||
(nvars.len() + 6) / 7 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't right, it should be 2^7
not 7
, we want to check how many variants fit in how many varint bytes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple thoughts that have been bouncing around in my head
/// | ||
/// You must not rely on this value for safety reasons, as implementations | ||
/// could be wrong. | ||
const MANUAL_MAX_SIZE: Option<usize> = None; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of having this manual override and a max_size()
function that checks it, this could default to the calculated size and be overridden as appropriate:
trait Schema {
const MAX_SIZE: Option<usize> = max_size_nt(Self::SCHEMA);
}
// Manual max size
impl Schema for heapless::Vec<T, N> {
const MAX_SIZE: Option<usize> = Some(...);
}
This seems more intuitive to me, since there'd be only one source of truth--T::MAX_SIZE
--instead of the separate override and calculator function.
assert!(nty_eq(nt, Inner::SCHEMA), "Mismatched Outer/Inner types!"); | ||
let size_one = max_size::<Inner>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this dance required to use Inner::MANUAL_MAX_SIZE
if it's set (as opposed to using max_size_nt()
)?
Somewhat relatedly, I'm wondering if it would make sense to embed known max sizes in the schema types somewhere in order for postcard-dyn
to be able to take them into account. Currently, from my understanding, a client using postcard-dyn
couldn't be told the max size of a heapless::Vec<T, N>
because the only information in the serialized schema is the unbounded Seq(T::SCHEMA)
. If the serialized schema included the max length, then that length could be used to size buffers even without knowing the concrete type.
Concretely, this could take the form of bundling an overall max size with an OwnedNameType
:
struct OwnedSchema {
ty: OwnedNamedType,
max_size: Option<usize>,
}
Or it could be more tightly coupled with the schema types themselves, something like:
struct NamedType {
name: &'static str,
ty: &'static DataModelType,
max_size: Option<usize>,
}
// In this case, Schema could remain as just a single associated const
trait Schema {
const SCHEMA: &'static schema::NamedType;
}
No description provided.