UpperHex/LowerHex trait should be implemented for &[u8]

[BusyJay]

It is a common use case to print a byte array in hex format. For example:

assert_eq!("0203", format!("{:x}", &[2u8, 3]));

And user can't implement this behaviour cleanly.

[bluss]

it would need to be format!("{:02x}", &[2u8, 3]) for the assertion to hold, requiring the formatter options to apply per element. I think it makes sense that way, but it's unprecedented unfortunately.

Edit: Looking even closer at the details, it does not really make sense to me to implicitly use no separator between the elements.

[nodakai]

+1. Let's discuss the details...

What shall we do if we want a space between elements? {:03x}? Then the first item will get an unnecessary space. What about a space and a comma? Perhaps we can utilize the "alternative format" # here.

Do you think we should have a way to limit the number of elements to print? Maybe we can repurpose the "precision" parameter for it but that might be too arbitrary and confusing.

Why do we limit Upper/LowerHex to [u8]? Are there anything inherently wrong with impl LowerHex for [i32] ? (Just for the sake of completeness...)

[bluss]

itertools has a method (.format_default()) that does elementwise lazy formatting with an explicit separator. That would rather be a good model for an addition to the libstd API (for example a method for an iterator).

[BusyJay]

I don't think we need to take care of custom delimiter, because neither currently implemented format traits of Vec support custom delimiter.

[bluss]

The default delimiter is ", " isn't it (what Vec uses in Debug)? So if you want to print them without anything separating the elements, maybe it needs to be specified.

[retep998]

I personally would prefer Debug style output, just with hex instead of decimal.

[ollie27]

I would like to see an easy way to format iterators where you can specify both a format string for each element and a delimiter.

[alexcrichton]

We tend to not keep track of feature requests in this repository any more, so nowadays this issue would be best suited for the rust-lang/rfcs repo. As a result I'm going to close, but thanks for the report!

[abonander]

@alexcrichton Why did this need to go to the RFCs repo? I wouldn't consider this a big enough change to require an RFC.

[abonander]

Opened rust-lang/rfcs#1916 anyway

[alexcrichton]

@abonander oh I didn't mean it required an RFC, just that feature requests go in rust-lang/rfcs issue tracker, not the rust-lang/rust issue tracker