support for `defmt`

[BurntSushi]

Specifically, defmt helps with formatting values in embedded scenarios where core::fmt doesn't work as well. My understanding of the underlying value proposition is that it provides "deferred" formatting. That it, there is some wire protocol where an efficient representation of values is transferred to the host machine and it's the host machine that does the actual formatting.

This was brought up in #168:

I spent a couple of hours working on this today. At this point, defmt works with all public-facing structs and enums in jiff. However, it does not currently work when either the std feature or the alloc feature is enabled. (This is because defmt only implements on Format trait on alloc::core::Box<T> where T is Sized)

There is some value in making defmt compatible with alloc, but the lack of support should not be a blocker for now as most embedded devices do not have an allocator.

One important caveat: Supporting defmt comes with the trade-off that, if you ever want to take on a third-party dependancy for jiff, you will need to the upstream dependency to support defmt, or will need to create wrapper structs. I do see that you depend on very few third party dependencies, so this may not be an issue.

I’m still verifying that we don’t rely on core::fmt anywhere. The entire value proposition of defmt is to reduce compile-time code size and defer formatting until logs are rendered on a debugger. If any part of the code still uses core::fmt at runtime, that benefit is lost, and we are wasting out time.

---

btw, thanks for getting back to me so quickly, I cannot say how refreshing that is.
Thank you so much for this library!

Originally posted by @dickermoshe in #168

[BurntSushi]

I see that defmt has a book: https://defmt.ferrous-systems.com/

But I can't find any guidance for library authors.

e.g., Are there supposed to be defmt impls for every Debug impl in the library? That strikes me as very excessive and not really something I'd want to maintain. But I could see doing it for every Display impl.

[BurntSushi]

@dickermoshe

I spent a couple of hours working on this today. At this point, defmt works with all public-facing structs and enums in jiff. However, it does not currently work when either the std feature or the alloc feature is enabled. (This is because defmt only implements on Format trait on alloc::core::Box where T is Sized)

There is some value in making defmt compatible with alloc, but the lack of support should not be a blocker for now as most embedded devices do not have an allocator.

This seems like a problem. Because it means feature unification will break things?

I don't think I understand why defmt is incompatible with alloc or std. Can you say more about this?

One important caveat: Supporting defmt comes with the trade-off that, if you ever want to take on a third-party dependancy for jiff, you will need to the upstream dependency to support defmt, or will need to create wrapper structs. I do see that you depend on very few third party dependencies, so this may not be an issue.

This seems okay. Jiff has a conservative dependency philosophy.

I’m still verifying that we don’t rely on core::fmt anywhere. The entire value proposition of defmt is to reduce compile-time code size and defer formatting until logs are rendered on a debugger. If any part of the code still uses core::fmt at runtime, that benefit is lost, and we are wasting out time.

Hmmm. I see. Does this mean that when defmt is enabled, you'd specifically not want the standard Debug and Display impls? That seems like a maintenance nightmare.

[dickermoshe]

I’ll write a longer response when I’m in print off my computer. Items that implement the defmt::Format trait are able to be logged using the defmt::info, defmt:warning etc. macros. There is no issue if these structs or enums implement Debug or Display as well. When a crate is compiled the unused core::fmt module will be tree shaken. The only thing you need to be cautious about is ensuring that the defmt::Format implementation Is not using core::fmt under the hood. For instance, the code to turn a float into a string is fairly large. The write!() macro Turns that into some sort of wire format, which is used to format the float on the host machine. So you just need to be careful that any of those implementations aren’t using any of this code at runtime. Example how to do it incorrectly: struct Bad { x: u32 } impl defmt::Format for Bad { fn format(&self, f: defmt::Formatter) { let s = format!("{}", self.x); // BAD: uses core/alloc formatting at runtime defmt::write!(f, "{=str}", s.as_str()) } }

…

On Mon, Feb 9, 2026 at 11:41 AM Andrew Gallant ***@***.***> wrote: *BurntSushi* left a comment (BurntSushi/jiff#505) <#505 (comment)> I see that defmt has a book: https://defmt.ferrous-systems.com/ But I can't find any guidance for library authors. e.g., Are there supposed to be defmt impls for *every* Debug impl in the library? That strikes me as very excessive and not really something I'd want to maintain. But I could see doing it for every Display impl. — Reply to this email directly, view it on GitHub <#505 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASDJ623U2DKI6QLC4P6YJQT4LC2FBAVCNFSM6AAAAACUPYIF5CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQNZSGI4TEMRTGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[dickermoshe]

The reason why we are not compatible with alloc is because Box<str> does not implement defmt::Format. These types cannot be logged by defmt. If we would like defmt to be compatible with alloc, we would need to ignore these types when formatting.

…

On Mon, Feb 9, 2026 at 12:42 PM Moshe Dicker ***@***.***> wrote: I’ll write a longer response when I’m in print off my computer. Items that implement the defmt::Format trait are able to be logged using the defmt::info, defmt:warning etc. macros. There is no issue if these structs or enums implement Debug or Display as well. When a crate is compiled the unused core::fmt module will be tree shaken. The only thing you need to be cautious about is ensuring that the defmt::Format implementation Is not using core::fmt under the hood. For instance, the code to turn a float into a string is fairly large. The write!() macro Turns that into some sort of wire format, which is used to format the float on the host machine. So you just need to be careful that any of those implementations aren’t using any of this code at runtime. Example how to do it incorrectly: struct Bad { x: u32 } impl defmt::Format for Bad { fn format(&self, f: defmt::Formatter) { let s = format!("{}", self.x); // BAD: uses core/alloc formatting at runtime defmt::write!(f, "{=str}", s.as_str()) } } On Mon, Feb 9, 2026 at 11:41 AM Andrew Gallant ***@***.***> wrote: > *BurntSushi* left a comment (BurntSushi/jiff#505) > <#505 (comment)> > > I see that defmt has a book: https://defmt.ferrous-systems.com/ > > But I can't find any guidance for library authors. > > e.g., Are there supposed to be defmt impls for *every* Debug impl in the > library? That strikes me as very excessive and not really something I'd > want to maintain. But I could see doing it for every Display impl. > > — > Reply to this email directly, view it on GitHub > <#505 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ASDJ623U2DKI6QLC4P6YJQT4LC2FBAVCNFSM6AAAAACUPYIF5CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQNZSGI4TEMRTGQ> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[BurntSushi]

OK, thanks that's helpful.

RE Box<str>, can we just format it as a &str instead?