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;
}

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

pub struct FromFn<F>(F)
where
    F: Fn(&mut fmt::Formatter<'_>) -> fmt::Result;

impl<F> fmt::Debug for FromFn<F>
where
    F: Fn(&mut fmt::Formatter<'_>) -> fmt::Result;

impl<F> fmt::Display for FromFn<F>
where
    F: Fn(&mut fmt::Formatter<'_>) -> fmt::Result;

Steps / History

• Implementation: Closure-consuming helper functions for fmt::Debug helpers #117730
• Update to from_fn API: Replace std::fmt:FormatterFn with std::fmt::from_fn #129017
• 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().
• The DebugMap struct got key_with() and value_with(), but not entry_with() -- is it worth adding that?
• 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.