implement fmt traits for collections #25319

skullzzz · May 12, 2015

reopen #20932
closes #19670

Still need to fix up tests and move them to libcollectionstest, but figured I should get comments on this implementation.

rust-highfive · May 12, 2015

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @huonw (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see CONTRIBUTING.md for more information.

Gankro · May 12, 2015

r? @Gankro

Gankro · May 12, 2015

Gankro reviewed May 12, 2015

View changes

Gankro · May 12, 2015

src/libcollections/format_helpers.rs

+use core::result::Result;
+
+pub fn seq_fmt_debug<I: Iterator>(s: I, f: &mut Formatter) -> fmt::Result
+    where I::Item:fmt::Debug


Missing a space after colon

(this is pretty much everywhere in this PR)

Gankro · May 12, 2015

Gankro reviewed May 12, 2015

View changes

Gankro · May 12, 2015

src/libcollections/format_helpers.rs

+    Result::Ok(())
+}
+
+pub fn vec_map_fmt_debug<K, V, I: Iterator<Item=(K, V)>>(s: I, f: &mut Formatter) -> fmt::Result


I don't see any obvious reason why vec_map is different from a normal Map?

Ah, you want to treat the keys special... I'm not sure that's the right call. In general I'd expect BTreeMap<usize, V> to be interchangeable with VecMap<V>. Any particular reason?

vec_map currently implements Debug this way, ie. write!(f, "{}: {:?}", k, v)
I wasn't sure if that was some convention I wasn't aware of so I didn't change the behavior.

I would just change the behaviour. Debug and Display are identical for primitives as far as I know, anyway.

Gankro · May 12, 2015

Gankro reviewed May 12, 2015

View changes

Gankro · May 12, 2015

src/libcore/array.rs

-                    fmt::Debug::fmt(&&self[..], f)
-                }
-            }
+            fmt_array! { $N, Debug, Display, Octal, Binary, UpperHex, LowerHex, UpperExp, LowerExp }


RIP rustdoc 💀

Is there something I can do to mitigate the issue?

Nah, this is a problem that needs to be solved at a higher level (generic integers or rustdoc patches).

Gankro · May 12, 2015

Gankro reviewed May 12, 2015

View changes

Gankro · May 12, 2015

src/libcore/fmt/mod.rs

+                    try!(write!(f, "["));
+                    let mut is_first = true;
+                    for x in self.iter() {
+                        if is_first {


Different style here than from everything else. (for (i, x) in iter.enumerate() { if i != 0 { .. } ..)

Intentional?

This was how Debug was implemented for [T] before the builder stuff landed. I assumed it was because enumerate() was in std::iter and this is implemented in libcore. I'll check.

std::iter is just a re-export of core::iter

Gankro · May 12, 2015

Gankro reviewed May 12, 2015

View changes

Gankro · May 12, 2015

src/libcore/fmt/mod.rs

@@ -1124,6 +1124,39 @@ impl<T: Debug> Debug for [T] {
    }
 }

+macro_rules! fmt_dst {


fmt_slice seems like a more appropriate name

Gankro · May 12, 2015

Gankro reviewed May 12, 2015

View changes

Gankro · May 12, 2015

src/test/run-pass/ifmt.rs

@@ -246,3 +248,96 @@ fn test_order() {
                       foo(), foo(), foo(), a=foo(), b=foo(), c=foo()),
               "1 2 4 5 3 6".to_string());
 }
+
+fn test_collections() {


I think this would be better placed in libcollectionstest. I think this file is mostly just verifying that the format macro itself works right.

oh derp right that was the thing you said at the top of the PR 🐫

Gankro · May 12, 2015

This is a pretty nice approach to the problem 👍

P1start · May 12, 2015

I feel like this would require an RFC—there are alternative approaches to this (e.g., adding formatting syntax for explicitly applying a formatter to the items in an iterable). Also, the precise details aren’t easy to settle on; e.g., should [1, 2, 3] format with Display as 1, 2, 3 or 1, 2, and 3? Or should sequences/maps not have Display formatters at all?

Gankro · May 12, 2015

@P1start There have been two RFCs, both of which provide guidance on collection formatting:

https://github.com/rust-lang/rfcs/blob/master/text/0565-show-string-guidelines.md
https://github.com/rust-lang/rfcs/blob/master/text/0640-debug-improvements.md

Gankro · May 12, 2015

Actually the first RFC explicitly states that Display should:

Not be implemented for generic containers like Vec or even Result<T, E>, where there is no useful, general way to tailor the output for user consumption.

Gankro · May 12, 2015

CC @aturon

Gankro · May 15, 2015

Oh! Just saw you added commits (Github doesn't notify anyone when that happens). Are you still working on stuff or are you ready for another pass?

skullzzz · May 15, 2015

Oops, I assumed new commits would send a notification.
I think I've covered all previously pointed out issues, so yeah, ready for another pass.

Gankro · May 18, 2015

r? @alexcrichton

It has come to my attention that current standards are ambiguous: Is Octal et al. Displayish, or Debugish? Needs decision.

bors · Jun 8, 2015

☔️ The latest upstream changes (presumably #25989) made this pull request unmergeable. Please resolve the merge conflicts.

alexcrichton · Jun 10, 2015

Thanks again for the PR @skullzzz! For now, though, there is enough consensus to merge this. There are remaining concerns about how ambitious collections should be in their formatting (especially when it comes to the various flags formatters have). It's also possible to add these formattings as adaptors if necessary, or just writing a helper method.

If you're interested in pursuing this, though, I'd recommend one of two courses of action:

I'd primarily recommend opening up a discuss post to gauge the interest in a feature like this along with how ambitious it should be. For example should this attempt to provide anything beyond the bare-bones formatting? If so, how would that be done?
You can also open up an RFC to get broader discussion about this.

One of the unfortunate parts about stability today is that any trait implementation is insta-stable, so there's a bit higher of a bar for entry for trait impls than new structures (as we can't introduce this as stable functionality).

implement fmt traits for collections

Loading status checks…

e9cfbc3

rust-highfive assigned huonw May 12, 2015

rust-highfive assigned Gankro and unassigned huonw May 12, 2015

rust-highfive assigned alexcrichton and unassigned Gankro May 18, 2015

Gankro added the I-needs-decision label May 18, 2015

alexcrichton added the T-libs label May 20, 2015

alexcrichton closed this Jun 10, 2015

skullzzz referenced this pull request Jun 11, 2015
Closed
Formatters for collections #19670

alexcrichton referenced this pull request Jun 16, 2015
Closed
core: impl LowerHex and UpperHex for [u8] #26331

rust-lang/rust

Join GitHub today

implement fmt traits for collections #25319

Conversation

skullzzz commented May 12, 2015

rust-highfive assigned huonw May 12, 2015

This comment has been minimized.

rust-highfive commented May 12, 2015

This comment has been minimized.

Gankro commented May 12, 2015

rust-highfive assigned Gankro and unassigned huonw May 12, 2015

Gankro reviewed May 12, 2015 View changes

This comment has been minimized.

This comment has been minimized.

Gankro reviewed May 12, 2015 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Gankro reviewed May 12, 2015 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Gankro reviewed May 12, 2015 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Gankro reviewed May 12, 2015 View changes

This comment has been minimized.

Gankro reviewed May 12, 2015 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Gankro commented May 12, 2015

This comment has been minimized.

P1start commented May 12, 2015

This comment has been minimized.

Gankro commented May 12, 2015

This comment has been minimized.

Gankro commented May 12, 2015

This comment has been minimized.

Gankro commented May 12, 2015

skullzzz added some commits May 12, 2015

This comment has been minimized.

Gankro commented May 15, 2015

This comment has been minimized.

skullzzz commented May 15, 2015

This comment has been minimized.

Gankro commented May 18, 2015

rust-highfive assigned alexcrichton and unassigned Gankro May 18, 2015

Gankro added the I-needs-decision label May 18, 2015

alexcrichton added the T-libs label May 20, 2015

This comment has been minimized.

bors commented Jun 8, 2015

This comment has been minimized.

alexcrichton commented Jun 10, 2015

alexcrichton closed this Jun 10, 2015

skullzzz referenced this pull request Jun 11, 2015

alexcrichton referenced this pull request Jun 16, 2015

Gankro reviewed May 12, 2015

View changes

Gankro reviewed May 12, 2015

View changes

Gankro reviewed May 12, 2015

View changes

Gankro reviewed May 12, 2015

View changes

Gankro reviewed May 12, 2015

View changes

Gankro reviewed May 12, 2015

View changes