[rust-dev] Preserving formatting for slice's Show impl

Kevin Ballard kevin at sb.org
Fri Jun 13 12:24:02 PDT 2014


I would not expect this to be “mapped” over the slice. I encourage you to come up with an appropriate syntax to describe that and submit an RFC, although I wonder how you plan on dealing with things like key vs value in Maps, and further nesting (e.g. slices of slices, etc).

As for applying it to the slice as a whole, that would be the appropriate way to handle this format parameter. The problem is doing that requires building an intermediate string first, because you have to know the length of the full output before you can know how to pad it, and it’s generally considered to be undesired work to do that. As far as I’m aware, the only types right now that actually support the various padding-related formatting controls are the ones that can be printed in a single operation (such as numbers, or strings).

-Kevin

On Jun 9, 2014, at 8:50 PM, Tom Jakubowski <tom at crystae.net> wrote:

> I would expect that `println!("{:_>4}", [1].as_slice());` would print either `[___1]` (where the format is "mapped" over the slice) or `_[1]` (where the format is applied to the slice as a whole), but instead no formatting is applied at all and it simply prints `[1]`. 
> 
> I can see uses and arguments for both the "mapping" and "whole” interpretations of the format string on slices. On the one hand this ambiguity makes a case for leaving the behavior as-is for backwards compatibility. On the other hand it would be useful to be able to format slices (and other collections, of course). Would it be appropriate to expand the syntax for format strings to allow for nested format strings, so that separate formatting can be applied to the entire collection and to its contents? I assume it this would require an RFC.
> 
> (The "mapped" variant can be very easily implemented, by the way, by replacing `try!(write!("{}", x))` with `try!(x.fmt(f))` in the `impl<T: Show> Show for &[T]`.)
> 
> Tom
> 
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140613/a20a1f30/attachment.html>


More information about the Rust-dev mailing list