diff --git a/content/2025-08-20-heapless-091.md b/content/2025-08-20-heapless-091.md new file mode 100644 index 0000000..4402ac4 --- /dev/null +++ b/content/2025-08-20-heapless-091.md @@ -0,0 +1,131 @@ ++++ +title = "Heapless v0.9.1 has been released!" +date = 2025-08-20 +draft = false +in_search_index = true +template = "page.html" ++++ + +Almost 2 years after the last release, the [heapless](https://github.com/rust-embedded/heapless) crate has a new release. The first attempt at a `0.9.0` release was yanked due to including more breaking changes than intended. This has been fixed, and `0.9.1` has been released today. + +Compared to `0.8.0`, the `0.9.1` release contains a bunch of small everyday improvements and bugfixes. Most users of the library should be able to adapt with minimal changes. For more information, you can check out [the changelog](https://github.com/rust-embedded/heapless/blob/main/CHANGELOG.md). Here are some of the major changes that can improve your usage of the library. + + + +# The `View` types + +One of the main constraints when working with `heapless` types is that they all have a `const generic`. In a lot of situations, these can now be removed thanks to the `View` types. + +A lot of embedded firmware will allocate a couple of buffers and pass them around to save on memory. +To make it easy to change the size of the buffers, functions will carry along these `const generics`: + +```rust +use heapless::Vec; +struct App{ + … +} + +impl App { + pub fn handle_request(input: &mut Vec, output: &mut Vec) -> Result<(), Error> { + … + } +} +``` + +The new `View` variants of the types enable you to remove the `const generics` while still keeping the same functionality: + +```rust +use heapless::VecView; +struct App{ + … +} + +impl App { + pub fn handle_request(input: &mut VecView, output: &mut VecView) -> Result<(), Error> { + … + } +} +``` + +Call sites of `handle_request` will be able to stay the same. The function will continue to accept `&mut Vec`. + +So what's the difference between `VecView` and `Vec`? + +There are almost none, both are aliases of the same underlying type `VecInner`. The only limitation of `VecView` compared to `Vec` is that `VecView` is `!Sized`. This means that you cannot perform anything that would require the compiler to know the size of the `VecView` at compile-time. You will always need to manipulate `VecView` through pointer indirection (generally a reference). This means you can't just create a `VecView` out of thin air. The `VecView` is always a runtime "View" of an existing `Vec`. + +So how can we obtain a `VecView` ? It's pretty simple: `Vec` can be *coerced* into a `VecView`. Coercion (in this case [`Unsized` coercion](https://doc.rust-lang.org/reference/type-coercions.html#r-coerce.unsize)), is a way the compiler can transform one type into another implicitly. In this case, the compiler is capable of converting pointers to a `Vec` (`&Vec`, `&mut Vec`, `Box>` etc...) to pointers to a `VecView` (`&VecView`, `&mut VecView`, `Box>` etc...), so you can use a reference to a `Vec` when a reference to a `VecView` is expected: + +```rust +use heapless::{VecView, Vec}; +struct App{ + … +} + +impl App { + pub fn handle_request(input: &mut VecView, output: &mut Vec) -> Result<(), Error> { + … + } +} + +let mut request: Vec = Vec::new(); +let mut reply: Vec = Vec::new(); + +app.handle_request(&mut request, &mut reply).unwrap(); +``` + +If you prefer things to be explicit, the `View` variants of types (`Vec` is not the only data structure having `View` variants) can be obtained through `vec.as_view()` or through `vec.as_mut_view()`. + +The pointer to the `VecView` is the size of 2 `usize`: one for the address of the underlying `Vec`, and one for the capacity of the underlying `Vec`. This is exactly like slices. `VecView` is to `Vec` what a slice `[T]` is to an array `[T; N]`. +Unless you need to store data on the stack, most often you will pass around `&mut [T]` rather than `&mut [T; N]`, because it's simpler. The same applies to `VecView`. Wherever you use `&mut Vec`, you can instead use `&mut VecView`. + +The `View` types are not available just for `Vec`. There are `View` versions of a lot of heapless types: +- `Vec` has `VecView` +- `String` has `StringView` +- `Deque` has `DequeView` +- `LinearMap` has `LinearMapView` +- `HistoryBuf` has `HistoryBufView` +- `BinaryHeap` has `BinaryHeapView` +- `mpmc::Queue` has `mpmc::QueueView` +- `spsc::Queue` has `spsc::QueueView` + (and now, the producer and consumer structs don't carry the const-generic) +- `SortedLinkedList` has `SortedLinkedListView` + +`IndexMap` and `IndexSet` are the two remaining structures that don't have a `View` type available. +We hope to be able to use it in the future. + +## Benefits of the view types + +The benefits are multiple: + +### Better compatibility with `dyn Traits` + +If a trait has a function that takes a generic, it is not `dyn` compatible. By removing the const generic, the `View` types can make `dyn Trait` pass around data structures without having to hard-code a single size of buffer in the trait definition. + +### Better binary size and compile times + +When you use const-generics, the compiler needs to compile a new version of the function for each value of the const-generic. +Removing the const generic means cutting down on duplicated functions that are all almost the same, which improves both compile time and the size of the resulting binary. + +### Better ergonomics + +The View types can remove a ton of excess noise from the generics. + +# The `LenType` optimization + +Most often, buffers in embedded applications will not contain a huge number of items. +Until `0.9.1` the capacity of a `heapless` data structure was almost always stored as a `usize`, which can often encode much more values than necessary. + +In 0.9.1, data structures now have a new optional generic parameter called `LenT`. This type accepts `u8`, `u16`, `u32`, and `usize`, and defaults to `usize` to keep typical uses of the library, simple. + +If you are seriously constrained by memory, a `Vec` (equivalent to `Vec`) can become a `Vec`, saving up to 7 bytes per `Vec`. This is not much, but in very small microcontrollers, it can make the difference between a program that uses all the memory available and one that just fits. + +# Contributors + +This release was made possible by [@Zeenix] joining the embedded working group as part of the libs team to help maintain `heapless` and convincing [@sgued] to do the same. + +The `View` types were a contributions from [@sgued], and the `LenType` were contributed by [@GnomedDev]. +In total 38 contributors participated in all the other improvements to the crate and helped with maintainance. + +[@zeenix]: https://github.com/zeenix +[@sgued]: https://github.com/sgued +[@GnomedDev]: https://github.com/GnomedDev