Tracking issue for access to Formatter alignment

[alexcrichton]

Tracking issue for the fmt_flags_align feature, which is fmt::Formatter::align and the associated enum.

[nagisa]

Should the formatting flags be boolean accessors?

Yes, please.

Should setters as well as getters be exposed?

Why? Makes little sense.

[alexcrichton]

I disagree that it makes little sense to expose getters, it's possible to envision a situation where one formatting is composed of many others and you perhaps want some to be formatted to various widths or perhaps enable various flags (e.g. the "alternate" mode). It's certainly niche but it's somewhat necessary for completeness.

[sfackler]

align, width, and precision all seem straightforward and can be stabilized as-is.

I would also very much like to add and stabilize boolean accessors for the various parts of flags: sign_plus, sign_minus, alternate, and zero_pad (we could call the last one sign_aware_zero_pad but that seems like a genuinely excessive name). It's pretty unfortunate we stabilized the flags accessor in the first place IMO, but oh well.

I'm a little less sure about fill, though. What char is returned if no fill character was specified? Why doesn't it return an Option like the others? Is char sufficient? Should it be a full grapheme instead?

[alexcrichton]

I'd be fine just deprecating the flags method (it's basically useless without constants anyway) and adding boolean accessors, I agree that it better matches design in today's Rust.

I'd also be fine making fill return an Option<char> and just specifying that it's always one unicode character (it's how the format string is parsed). Perhaps in theory a grapheme could be specified but that seems like something for an even fancier formatting system!

[alexcrichton]

This issue is now entering its cycle-long FCP for stabilization in 1.5

The accessors being added in #28615 will also be considered for stabilization.

[alexcrichton]

Ah, and @SimonSapin, may be good to get your opinion on the grapheme-vs-char situation here. Currently whenever something is formatted you have the ability to specify a "fill" character which for when padding is applied (normally this is just an ascii space). As @sfackler points out this fill is currently just a char, but it could in theory be a grapheme in terms of "one thing on the screen". Do you have an opinion either way in that regard? Curious to hear thoughts!

[SimonSapin]

Uh. It’s not just graphemes. The whole width/align/fill thing in std::fmt as currently written is based on some assumptions:

1. We’re printing to something that (like most terminal emulators) align text on a grid
2. The number of grid slots occupied by a piece of text is the number of UTF-8 bytes (&str::len).
3. It’s the number of char code points
4. Printing a char occupies one slot on the grid

Unfortunately, as often with Unicode, it’s complicated. Not only grapheme clusters can have more than one code point and still only use one slot (with combining code points), but most characters of some Asian languages and most emoji are “full width”: they’re twice the usual width in most monospace fonts. Control characters might or might not be displayed. Or they might be interpreted by the terminal to move the cursor around.

http://eev.ee/blog/2015/09/12/dark-corners-of-unicode/#combining-characters-and-character-width has some more background. Here is an extract, about emoji flags:

So the “length” of a pair of these characters depends both on the display font (which may not support all flags), and on the current geopolitical state of the world. How’s that for depending on global mutable state?

---

Our best bet for ”what is the width of this string?” is probably https://github.com/unicode-rs/unicode-width

That leaves dealing with fill if it’s double width or a control character. If we want to do it, could fill be an arbitrary string rather than a single char? Or should width(fill) != 1 be rejected?

[alexcrichton]

Hm, those are very good points! I would be mostly tempted to just pare down everything and say it largely deals with ascii only (and maybe simple unicode?). I don't think it'd be too beneficial to start getting full-blown unicode-width support in libcore just to support a use case like this.

Having some verification in the compiler, however, to make sure you're not doing crazy things seems reasonable?

If we want to do it, could fill be an arbitrary string rather than a single char?

In theory, yes.

Or should width(fill) != 1 be rejected?

I'd also be fine with this!