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 struct FormatterFn<F>(pub F)
where
    F: Fn(&mut Formatter) -> fmt::Result;

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

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

Steps / History

• Implementation: Closure-consuming helper functions for fmt::Debug helpers #117730
• 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.

[SUPERCILEX]

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

[its-the-shrimp]

The change suggested above has just been merged into master, the description of the issue should be changed to reflect the new API

[01mf02]

Thanks for your work, @its-the-shrimp!