snow
snow copied to clipboard
mcginty
investigate ways to avoid heap allocations
Right now for the sake of cleaner syntax, there's allocation being done using Box structs to avoid forcing users of snow to specify a ton of ugly generics when they store sessions in their own structs, for example.
It would be an option to use impl Trait. Unfortunately, this does not allow users to store the results in their own structs.
Maybe associated types would help?
@vks I think we'd need impl Trait to extend support for being used in structs, which it currently can't do and I'm not sure what the roadmap is for that.
If you have any suggestions for associated types I'm all ears! Another thought I had was to simply disallow external resolvers and use enums to avoid allocations, but of course that comes as a compromise.
Why is snow doing Box<dyn SomeTrait> everywhere rather than &'a SomeTrait? Is it because the explicit lifetimes would make it harder for snow users?
@isislovecruft yep, it's purely for ergonomic reasons. I'd love to use something like associated traits and maybe a convenience macro to be able to drop the Boxes while keeping roughly the same level of simplicity.
If you want trait objects without heap allocations, one option is an enum with Deref impl whose Target is the desired trait object. Something like this:
enum CipherBackends {
#[cfg(feature = "backend1")]
....
}
impl core::ops::Deref for CipherBackends {
type Target = dyn Cipher;
fn deref(&self) -> &(dyn Cipher + 'static) {
match self {
#[cfg(feature = "backend1")]
....
}
}
}
This should work more or less the same as Box<Cipher>, but avoids keeping data on the heap.
Note that this does have the advantage that the size of CipherBackends will always be as big as the largest of the variants, but hopefully they're roughly the same size.
@tarcieri the reason I didn't choose this method in the original design is because I wanted the option for people to implement their own crypto backends if snow didn't provide any that fit their needs. If it's totally clear that flexibility isn't necessary, we could definitely switch to something like this.
Unfortunately I think you need either Box or a generic type parameter in that case, the former requiring a heap allocation, and the latter defeating the point of using an enum since it can just monomorphize rather than using a trait object.