Currently, precision is enforced by optionally truncating to a fixed number of digits behind the comma .# or to a significant amount of digits ~#. Usually, this is undesired for displaying numbers and rounding is preferred.

Examples of desired behaviour

static rounding

• [.3] 42069.69 => "42069.690"; trailing "0" gets added
• [.2] 42069.69 => "42069.69"; nothing happens
• [.1] 42069.69 => "42069.7"; rounded to 0.1s
• [.0] 42069.69 => "42070"; rounded to whole numbers
• [.-1] 42069.69 => "42100"; rounded to 10s
• ...
• [.-5] 42069.69 => "0"; rounded to 100000s, rounds number away completely

dynamic rounding

• [~5] 69.69 => "69.690"; trailing "0" gets added
• [~4] 69.69 => "69.69"; nothing happens
• [~3] 69.69 => "69.7"
• [~2] 69.69 => "70"
• [~1] 69.69 => "70"
• [~0] 69.69 => "0"; always returns "0"
• [~-1] invalid option

In metric scaling mode m, please add the corresponding metric prefixes for numbers smaller than 1, like milli, mikro, nano, pico, femto, atto...

• 10^(-3) => "1m"
• 10^(-6) => "1µ"
• 10^(-9) => "1n"
• ...

It would make sense to default to scientific notation only when metric prefixes are exhausted. Currently, the smallest metric prefix is "quecto" meaning 10^(-30). Only a number < 10^(-30) should be written in scientific notation.

Same behaviour on the other side: The biggest metric prefix is "quetta" at 10^30. I would expect a number going up to "999.99999Q" and as soon as it reaches 10^(33), where no metric prefix is defined, scientific notation should kick in.

I personally am also of the opinion no fallback to scientific notation should kick in "no scaling mode" n, but that's another topic.

I had been using Formatter::fmt and casting my integer types to f64 to use it. I just did a cargo update, got told fmt was deprecated and to use fmt2. Saw that it supports any Numeric type. I thought "Great! I can use my integer types directly now, and avoid the cast I didn't want." I took the cast off of a u64 and passed it into fmt2 and was very surprised when the trait bound failed. As far as I can tell, after looking, it appears that there are Numeric trait impls for signed and unsigned 8, 16, 32, and 128 bit integers. Is there a reason we skipped 64-bit? It's the native register size on x86_64 architecture, as well as being a very useful size. I think this is simply missing, and should be present.

As far as I know, there is currently only the option to manually define the 1000 separator with /<char>. Please also add the option to manually define a decimal separator. If this is something already possible, I could not find anything regarding that option in the readme.md.

Hi, would you accept contribution in order to add or modify some feature so they could be used for other types of floats int : bigints bigfloats and custom ones?
If so I would be interested in implementing this (in order to use it in typst)