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)¹ Tracking Issue for debug_more_non_exhaustive #127942 (comment)
• Stabilization PR Stabilize debug_more_non_exhaustive #131109

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.

[tgross35]

I think that is a good idea, guess libs-api feedback is needed.

@rustbot label +I-libs-api-nominated

Requesting discussion about whether we should replace the current unstable API with @clarfonthey's suggestion above. This would mean something like .elided_fields()/.elided_entries() methods that print .. at any position. Whether we want the same thing for DebugStruct, which already has finish_non_exhaustive, should also be considered (see #127942 (comment)).

(Name suggestions welcome, skipped_fields?)

[clarfonthey]

Note that like I mentioned, I don't think that DebugStruct needs this since the fields in a struct can be reordered but the .. must always be at the end, whereas lists and maps do have an explicit order to their fields.

[joshtriplett]

We discussed this in today's @rust-lang/libs-api meeting. We'd like to stabilize these four finish_non_exhaustive methods as-is.

We may also be amenable to adding elided_xyz() methods to show elisions in the middle of an array/tuple/struct/etc, but that'd be separate.

[joshtriplett]

FCP to stabilize:

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.