Tracking Issue for `debug_closure_helpers`

[jmillikin]

Feature gate: #![feature(debug_closure_helpers)]

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

ACP: rust-lang/libs-team#288

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

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?

Footnotes

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

[QuineDot]

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?)

[steffahn]

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<'_>.

[workingjubilee]

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.

[workingjubilee]

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.

[01mf02]

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?

[workingjubilee]

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