Add blog post for heapless release 0.9.1

Author: sgued

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.
+
+<!-- more -->
+
+# 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<const N: usize, const M: usize>(input: &mut Vec<u8, N>, output: &mut Vec<u8, M>) -> 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<u8>, output: &mut VecView<u8>) -> Result<(), Error> {
+	     …
+     }
+}
+```
+
+Callsites of the `handle_request` will essentially be able to stay the same, the function will continue to accept `Vec<u8, N>`. 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<T>`, `&mut Vec<T>`, `Box<T>` 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<u8>, output: &mut Vec<u8>) -> Result<(), Error> {
+	     …
+     }
+}
+
+let mut request: Vec<u8; 256> = Vec::new();
+let mut reply: Vec<u8; 256> = 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<T>` is to `Vec<T, N>` 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<T, N>`, you can instead use `&mut VecView<T>`.
+
+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<T, 28>` can become a `Vec<T, 28, u8>`, 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.