Change:
Currently, the Debug of prints the underlying bytes, rather than the chars: Returns: As I was trying to work out what was (whether it was unicode points or bytes or something else), the first output was v confusing - is there a reason we don't print something like the second case? Would you take a PR to change this? I couldn't find any previous discussion on this - was the closest I could find.
The first one is UTF-8 bytes. You see this because the impl for is auto-generated: Strictly speaking, since the bytes inside of should always be valid UTF-8, this could have a custom impl that makes it pretend to contain a string by formatting the member as . The reason it doesn't display as individual chars is because it doesn't have individual ; determining their boundaries is the entire point of the iterator. I suppose this same argument could be used against the call to , which needs to scan the whole string to validate it. (but then the solution seems to be to use , which seems awfully heavy-handed for a impl. And perhaps it doesn't even matter, because the cost of most impls probably outweighs the cost of this validation) I guess that, questionable concerns of efficiency aside, my main concern is simply that showing a list of individual chars would be... dishonest, I guess.
Do & contain more data than ? I had thought they both contained the underlying bytes and then these were decoded as needed - including as part of the & implementations
No, they contain the same data. They're all just UTF-8 bytes. And the implementation of simply writes the bytes contained in the directly to the instance. Suppose we are writing to STDOUT. On UNIX, the impl writes these bytes directly to the underlying file descriptor with no processing: I would imagine this is because the console on any UNIX platform almost certainly uses UTF-8.[^1] It is your terminal application that is then responsible for decoding these bytes and producing glyphs. Considering that UTF-8 dominates much of the web space as well, it's quite possible that even on the playground, these bytes are ultimately sent over the wire to your PC with minimal processing, where your browser is responsible for decoding and displaying them. On Windows, transcodes the UTF-8 into the UTF-16 format expected by the windows APIs: and then Windows does whatever it does with those UTF-16 code units. (Quite likely, it hands them directly to the console, which is then responsible for decoding and displaying them) [^1]: (I think in actuality UNIX accepts arbitrary strings of bytes, and then the portions of these strings which are valid UTF-8 are rendered appropriately by the console. I don't know; doesn't really matter)
OK, so given that - is there still an objection to displaying the unicode characters for but not ?

Discussion:
} #[test] <ins> fn test_chars_debug() { let s = "ศไทย中华Việt Nam"; let c = s.chars(); assert_eq!( format!("{:?}", c), r#"Chars(['ศ', 'ไ', 'ท', 'ย', '中', '华', 'V', 'i', 'ệ', 't', ' ', 'N', 'a', 'm'])"# ); } #[test] </ins> fn test_bytesator() { let s = "ศไทย中华Việt Nam"; let v = [

/// /// [`chars`]: ../../std/primitive.str.html#method.chars /// [`str`]: ../../std/primitive.str.html <del> #[derive(Clone, Debug)] </del> <ins> #[derive(Clone)] </ins> #[stable(feature = "rust1", since = "1.0.0")] pub struct Chars<'a> { iter: slice::Iter<'a, u8>

} } <ins> #[stable(feature = "chars_debug_impl", since = "1.38.0")] impl fmt::Debug for Chars<'_> { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { write!(f, "Chars(")?; f.debug_list().entries(self.clone()).finish()?; write!(f, ")")?; Ok(()) } } </ins> #[stable(feature = "rust1", since = "1.0.0")] impl<'a> DoubleEndedIterator for Chars<'a> { #[inline]