Tracking Issue for debug_more_non_exhaustive

[tgross35]

Feature gate: #![feature(debug_more_non_exhaustive)]

This is a tracking issue for the non_exhaustive() function on fmt::Debug{List, Map, Set, Tuple}, which provides an easy way to omit fields with ...

Public API

// core::fmt

impl<'a, 'b: 'a> DebugList<'a, 'b> {
    pub fn finish_non_exhaustive(&mut self) -> Result<(), Error>;
}

impl<'a, 'b: 'a> DebugMap<'a, 'b> {
    pub fn finish_non_exhaustive(&mut self) -> Result<(), Error>;
}

impl<'a, 'b: 'a> DebugSet<'a, 'b> {
    pub fn finish_non_exhaustive(&mut self) -> Result<(), Error>;
}

impl<'a, 'b: 'a> DebugTuple<'a, 'b> {
    pub fn finish_non_exhaustive(&mut self) -> Result<(), Error>;
}

Steps / History

• ACP: ACP: Add finish_non_exhaustive to DebugList, DebugMap, andDebugTuple libs-team#248
• Implementation: Implement debug_more_non_exhaustive #127945
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

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

[clarfonthey]

Small bit of feedback as I'm looking through this, but it feels like it might be useful to actually have the non_exhaustive marker anywhere inside these, rather than just at the end.

Example where it'd be useful: I'm working on a tool to help more easily verify that double-ended iterators are working, and they accumulate their data into a VecDeque that gets rotated back to the correct position once everything has been accumulated. Therefore, when displaying this data in a Debug impl, it would make more sense to indicate the "non-exhaustive" marker in the middle of the list, rather than at the end, since the missing elements will end up between the ones that have already been added to the beginning and end.

While structs have no order to their fields (and thus, adding to the end is appropriate every time), lists do have relevant order here, and it feels reasonable to put the marker in the middle.

For now, I'll just add a RangeFull entry anyway since that covers it, but it feels like it would be reasonable to do it as a field rather than just a finish_non_exhaustive like structs do it.

[tgross35]

That is an interesting idea. Are you imagining that this would be something like .field_elided().finish() rather than .finish_non_exhaustive()?

[clarfonthey]

That's pretty much what I was thinking. I hadn't thought of a good name for it, but, yes.