std::fmt future-proofing: should `precision` be static error for integral types?

[pnkfelix]

(spawned off of #24662)

The docs for the precision formatting parmeter http://doc.rust-lang.org/nightly/std/fmt/index.html#precision currently say:

For integral types, this has no meaning currently.

What that text apparently means today is "we silently ignore any such parameter"

The phrase "has no meaning currently" to me implies that we might add meaning in the future.

I do not even know if we could make this be a static error in a reasonable way for 1.0. But I figured I would ask the question: Should we consider trying to do so? Or should we just commit, for purposes of backwards compatibility, to this being a no-op for integral parameters?

[pnkfelix]

nominating (for needs-decision, basically).

[sfackler]

A somewhat related question would be "do we even make any back compat guarantees with respect to the output of formatters?" We obviously won't want to do anything totally crazy like making the default output format for integers hex, but will/should anyone care if we do start using the precision parameter in the future?

As one example, the Debug improvements RFC noted using the precision or width formatter to specify the indentation size in multi-line output as a possible future extension.

[pnkfelix]

I think someone using format! to generate output that is intended to be read by other tools would very much care if we were to silently change the behavior of the precision parameter for the Display trait. It seems like it could be a very nasty bug for someone to track down from one Rust release to the next.

(That's essentially why I'm suggesting we consider trying to catch no-op cases like this today.)

(I also think that we would be within our rights to arbitrarily change the output behavior for the Debug trait.)

[pnkfelix]

Consensus is to just say "is ignored for integral types", i.e. get rid of the word "currently" that implies it may change in the future.