Add support for no-alloc using static lifetime ref Box and Vec types #44
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.
What
Add some super limited support for type construction in no-alloc envs using static lifetime ref
Box
andVec
types, used whenever thealloc
feature is disabled. Thealloc
feature is dependent on thealloc
crate'sBox
andVec
, and is enabled wheneverstd
is enabled.This results in three tiers of capabilities:
std
, type construction using the default allocator for recursive types (that useBox
) andVec
s, and encoding/decoding.alloc
, type construction using the default allocator for recursive types (that useBox
) andVec
s.Vec
s.Why
This crate has good support for
no_std
environments, but not for environments that require no allocator. That's because the XDR types for the Stellar protocol are recursive, and so we can't easily drop-in stack based Vec types like heapless. There are some uses of this lib in no alloc environments that involve using the types for structured programming without us actually needing encoding/decoding. This PR makes that possible without changing the interface of passing an allocator around. Ideally in #39 this is revisited and an allocator is passed down instead.Known limitations
These changes are temporary, and will be replaced when #39 is addressed.