Change:
fn float_to_exponential_common<T>(fmt: &mut Formatter, num: &T, upper: bool) -> Result where T: flt2dec::DecodableFloat { <del> let force_sign = fmt.flags & (1 << (FlagV1::SignPlus as u32)) != 0; </del> <ins> let force_sign = fmt.sign_plus(); </ins> let sign = match force_sign { false => flt2dec::Sign::Minus, true  => flt2dec::Sign::MinusPlus,

Discussion:
Tracking issue for the feature, which is  and the associated enum.
Yes, please. Why? Makes little sense.
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.
, , and 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 : , , , and (we could call the last one but that seems like a genuinely excessive name). It's pretty unfortunate we stabilized the accessor in the first place IMO, but oh well. I'm a little less sure about , though. What is returned if no fill character was specified? Why doesn't it return an like the others? Is sufficient? Should it be a full grapheme instead?
I'd be fine just deprecating the 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 return an 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!
This issue is now entering its cycle-long FCP for stabilization in 1.5 The accessors being in will also be considered for stabilization.
Ah, and may be good to get your opinion on the grapheme-vs- 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 points out this fill is currently just a , 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!
Uh. It’s not just graphemes. The whole // thing in as currently written is based on some assumptions: ’re printing to something that (like most terminal emulators) align text on a 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 be displayed. Or they might be interpreted by the terminal to move the cursor around. has some more background. Here is an extract, about emoji flags: Our best bet for ”what is the width of this string?” is probably That leaves dealing with if it’s double width or a control character. If we want to do it, could be an arbitrary string rather than a single ? Or should be rejected?
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? In theory, yes. I'd also be fine with this!
The libs team discussed this during triage today and the decision was to stabilize.
Triage: looks like this was stabilized, closing!
is still unstable, linking to this issue:
I am a bit confused about the reason is still unstable. Is it because is only available from ? Is there anything I can help with to move this along?
Nominating for stabilization. I suspect that needs to be re-exported in std, but that seems like something trivial to solve while stabilizing. The only concern that I see left is that there appear to be 3 separate, but equivalent, definition of the enum in the various libraries. These should probably be de-duplicated, but again, since only one appears to be public, we can probably do this trivially as well during stabilization.
I think we should remove and return an instead, but it seems reasonable to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period.

If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
Shouldn't this get merged then?
Yes, with FCP to stabilize completed, the next step is a stabilization PR.