From 35aa103345d80fcc8e9476d20150b304f888677e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Sosth=C3=A8ne=20Gu=C3=A9don?= Date: Tue, 19 Aug 2025 21:51:27 +0200 Subject: [PATCH 1/2] Add blog post for heapless release 0.9.1 --- content/2025-08-20-heapless-091.md | 108 +++++++++++++++++++++++++++++ 1 file changed, 108 insertions(+) create mode 100644 content/2025-08-20-heapless-091.md diff --git a/content/2025-08-20-heapless-091.md b/content/2025-08-20-heapless-091.md new file mode 100644 index 0000000..1e91632 --- /dev/null +++ b/content/2025-08-20-heapless-091.md @@ -0,0 +1,108 @@ ++++ +title = "Heapless v0.9.1 has been released!" +date = 2025-08-20 +draft = false +in_search_index = true +template = "page.html" ++++ + +# Heapless `0.9.1` released + +Almost 2 years after the last release, the [heapless](https://github.com/rust-embedded/heapless). 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 be removed thanks to the `View` types. + +A lot of embedded firmware will allocated a couple of buffers and pass them around to save on memory. +To make it easy to change the size of the buffers, a lot of 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 will 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> { + … + } +} +``` + +Callsites of the `handle_request` will essentially be able to stay the same, the function will continue to accept `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 that `VecView` has 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. In practice, 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 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](https://doc.rust-lang.org/reference/type-coercions.html) (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 implicitely. In this case, the compiler is capable of converting pointers to a `Vec` (`&Vec`, `&mut Vec`, `Box` etc...) to pointers to a `VecView`, so you can use a reference to a `Vec` when a reference to a `VecView` is exepected: + +```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 datastructure 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. + +## 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` can pass around data structures without having to hard-code a single size of buffer in the trait definition. + +### Better ergonomics + +The View types can remove a ton of excess noise from the generics. + +### 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 function that are all almost the same, which improves both compile time and the size of the resulting binary. + +# The `LenType` optimization + +Most often, buffers in embedded applications will not contain a huge number of items. +However, until `0.9.1` their capacity was almost always stored as a `usize`, which can often encode much more values than necessary. + +In 0.9.1, most 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 uses of the library simple. + +If you are seriously constrained by memory, a `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. + +This release was made possible by [@sgued] and [@zeenix] joining the embedded working group as part of the libs team. From 96a881e9a7f84cb98364cf27d482df9df867aa58 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Sosth=C3=A8ne=20Gu=C3=A9don?= Date: Tue, 19 Aug 2025 22:03:31 +0200 Subject: [PATCH 2/2] Prepare announcement for release 0.9.1 --- content/2025-08-20-heapless-091.md | 73 ++++++++++++++++++++---------- 1 file changed, 48 insertions(+), 25 deletions(-) diff --git a/content/2025-08-20-heapless-091.md b/content/2025-08-20-heapless-091.md index 1e91632..4402ac4 100644 --- a/content/2025-08-20-heapless-091.md +++ b/content/2025-08-20-heapless-091.md @@ -6,9 +6,7 @@ in_search_index = true template = "page.html" +++ -# Heapless `0.9.1` released - -Almost 2 years after the last release, the [heapless](https://github.com/rust-embedded/heapless). 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. +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. @@ -16,10 +14,10 @@ Compared to `0.8.0`, the `0.9.1` release contains a bunch of small everyday imp # 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 be removed thanks to 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 allocated a couple of buffers and pass them around to save on memory. -To make it easy to change the size of the buffers, a lot of functions will carry along these `const generics`: +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; @@ -28,13 +26,13 @@ struct App{ } impl App { - pub fn handle_request(input: &mut Vec, output: &mut Vec) -> Result<(), Error> { + pub fn handle_request(input: &mut Vec, output: &mut Vec) -> Result<(), Error> { … } } ``` -The new `View` variants of the types will enable you to remove the `const generics` while still keeping the same functionality: +The new `View` variants of the types enable you to remove the `const generics` while still keeping the same functionality: ```rust use heapless::VecView; @@ -49,10 +47,13 @@ impl App { } ``` -Callsites of the `handle_request` will essentially be able to stay the same, the function will continue to accept `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 that `VecView` has 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. In practice, 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 a runtime "View" of an existing `Vec`. +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`? -So how can we obtain a `VecView` ? It's pretty simple: `Vec` can be *coerced* into a `VecView`. [Coercion](https://doc.rust-lang.org/reference/type-coercions.html) (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 implicitely. In this case, the compiler is capable of converting pointers to a `Vec` (`&Vec`, `&mut Vec`, `Box` etc...) to pointers to a `VecView`, so you can use a reference to a `Vec` when a reference to a `VecView` is exepected: +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}; @@ -66,18 +67,31 @@ impl App { } } -let mut request: Vec = Vec::new(); -let mut reply: Vec = Vec::new(); +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 datastructure having `View` variants) can be obtained through `vec.as_view()` or through `vec.as_mut_view()`. +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. +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 @@ -85,24 +99,33 @@ 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` can pass around data structures without having to hard-code a single size of buffer in the trait definition. - -### Better ergonomics - -The View types can remove a ton of excess noise from the generics. +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 function that are all almost the same, which improves both compile time and the size of the resulting binary. +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. -However, until `0.9.1` their capacity was almost always stored as a `usize`, which can often encode much more values than necessary. +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 -In 0.9.1, most 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 uses of the library simple. +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. -If you are seriously constrained by memory, a `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. +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. -This release was made possible by [@sgued] and [@zeenix] joining the embedded working group as part of the libs team. +[@zeenix]: https://github.com/zeenix +[@sgued]: https://github.com/sgued +[@GnomedDev]: https://github.com/GnomedDev