Tracking Issue for debug_closure_helpers

Feature gate: #![feature(debug_closure_helpers)]

This is a tracking issue for adding helpers to core::fmt that can use closures for formatting values.

Public API

// core::fmt

impl DebugList<'_, '_> {
    fn entry_with<F>(&mut self, entry_fmt: F) -> &mut Self
    where
        F: FnOnce(&mut Formatter) -> fmt::Result;
}

impl DebugMap<'_, '_> {
    fn key_with<F>(&mut self, key_fmt: F) -> &mut Self
    where
        F: FnOnce(&mut Formatter) -> fmt::Result;
    
    fn value_with<F>(&mut self, value_fmt: F) -> &mut Self
    where
        F: FnOnce(&mut Formatter) -> fmt::Result;
}

impl DebugSet<'_, '_> {
    fn entry_with<F>(&mut self, entry_fmt: F) -> &mut Self
    where
        F: FnOnce(&mut Formatter) -> fmt::Result;
}

impl DebugStruct<'_, '_> {
    fn field_with<F>(&mut self, name: &str, field_fmt: F) -> &mut Self
    where
        F: FnOnce(&mut Formatter) -> fmt::Result;
}

impl DebugTuple<'_, '_> { // also DebugSet
    fn field_with<F>(&mut self, field_fmt: F) -> &mut Self
    where
        F: FnOnce(&mut Formatter) -> fmt::Result;
}

Steps / History

Implementation: Closure-consuming helper functions for fmt::Debug helpers #117730
Moved FormatterFn / FromFn / from_fn to separate tracking issue: Tracking Issue for fmt_from_fn #146705
Final comment period (FCP)¹
Stabilization PR: Stabilize debug_closure_helpers #146099

Unresolved Questions

Naming: Do any strong preferences exist regarding the new method names?
- For now I've named them {orig_method}_with, for example DebugStruct::field_with() is like DebugStruct::field().
- Resolved: The FormatterFn type was renamed to FromFn (and wrapped in from_fn(), the helper methods kept their original names.
The DebugMap struct got key_with() and value_with(), but not entry_with() -- is it worth adding that?
- Resolved to not add entry_with; see Replace Debug::{key_with, value_with} with DebugMap::entry_with libs-team#563 (comment)
Should FormatterFn<F> place a trait bound on F so that call sites can be tidier?

https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

Auto merge of rust-lang#117730 - jmillikin:fmt-debug-helper-fns, r=cu…

Rollup merge of rust-lang#117730 - jmillikin:fmt-debug-helper-fns, r=…

Unrolled build for rust-lang#117730

Taking inspiration from iter::from_fn, I suggest a module level helper function:

core::fmt::from_fn<F>(f: F) -> FormatterFn<F>
where
    F: Fn(&mut Formatter<'_>) -> Result
{
    FormatterFn(f)
}

Plus perhaps also

Renaming the struct to fmt::FromFn
Making the field private
Removing the bound from the struct definition

Is there any particular reason it doesn't implement Binary, LowerExp, etc? (Why both Debug and Display but not all formats?)

Is there any particular reason it doesn't implement Binary, LowerExp, etc? (Why both Debug and Display but not all formats?)

With “just” Debug and Display it would kind-of follow the precedent of fmt::Arguments<'_>.

these are really nice btw. I think QuineDot's suggestion could be a cool refactoring of this, but it's very nice to be able to basically randomly throw in a simple closure that provides debug formatting, without having to roll the internals yourself, since it's just... like, the case you're most likely doing this, you're already implementing some kind of explicit Debug or "Debug adapter" and you don't wanna have to do another one for every custom field.

QuineDot's suggestion is in fact very close to one of the listed alternatives in the original idea! The main difference is the use of a free higher-order function instead of a constructor, which might be better for type inference reasons.

@QuineDot

I would love to see just fmt::from_fn stabilised, as suggested by @QuineDot. The symmetry with iter::from_fn is apparent, and this seems relatively uncontroversial. What is the status of stabilising this?

someone would need to PR fmt::from_fn, to start.

Rollup merge of rust-lang#129017 - its-the-shrimp:core_fmt_from_fn, r…

Unrolled build for rust-lang#129017

Is there anything remaining for stabilization? These are super useful.

This feature was stabilized and released in Rust 1.93 (https://blog.rust-lang.org/2026/01/22/Rust-1.93.0/). Should this issue (and the PR?) be closed?

Are you referring to fmt_from_fn? That was split off from this one #146705, the remaining API here is still unstable https://doc.rust-lang.org/std/fmt/struct.DebugList.html#method.entry_with.

I missed that the feature was split. Sorry to bother you.

Fix Rust wrapper on stable Rust (specta typescript opt-in)

Rollup merge of rust-lang#159302 - connortsui20:dyn-debug-helpers, r=…

Unrolled build for #159302

feat(next): add Tauri command IPC infrastructure (P10 chunk 10.1)

Rollup merge of rust-lang#146099 - coolreader18:stabilize-debug_closu…

Unrolled build for #146099 in rollup 163774

Navigation Menu

Repository navigation

Tracking Issue for `debug_closure_helpers` #117729

Public API

Steps / History

Unresolved Questions

80 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for debug_closure_helpers #117729

Description

Public API

Steps / History

Unresolved Questions

Footnotes

Activity

QuineDot commented on Dec 3, 2023

steffahn commented on Mar 3, 2024

workingjubilee commented on May 5, 2024

workingjubilee commented on May 6, 2024

01mf02 commented on Jun 18, 2024

workingjubilee commented on Jun 29, 2024

SUPERCILEX commented on Aug 13, 2024

80 remaining items

jendrikw commented on Apr 18, 2026

tgross35 commented on Apr 18, 2026

jendrikw commented on Apr 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tracking Issue for `debug_closure_helpers` #117729