Please allow f64 counters

[peterbourgon]

I've seen #367 but want to raise this issue again.

As mentioned in that issue: counters, gauges, and histograms are all well-defined to have the same value type, which is f64. By constraining counter! to u64, metrics-rs makes it impossible to model many common counter use cases. For example, anything involving time is expected to use the unit of "seconds", but without sub-second (i.e. f64) precision, this isn't feasible.

I appreciate the desire to use the type system to prevent negative counter increments, and that's fine as an option, even a default option. But you can still enforce monotonicity for f64 counters! Just at runtime, instead of compile time. Which is totally fine. And, really, necessary.

[mladedav]

But you can still enforce monotonicity for f64 counters! Just at runtime, instead of compile time.

There's a problem with this in how should that work? If someone tries to do a negative increment, the library can

• panic, which a library like metrics shouldn't do ever
• silently not count the counter which would probably lead to very hard to debug problems
• not count the counter and throw in there a tracing::error! or eprintln! or similar which would be either annoying for applications trying to have structured output or simply hard to find
• return Result from all increments just because some types might have negative increments and expect users to handle this in all callsites
• instead of f64 accept a custom PositiveF64 which the caller has to construct in a similar fashion to NonZeroXxx, proving the invariant

Or in the case you had, you could just use a different unit, e.g. microseconds and use u64.