motivation: It is not currently possible to record floating point values via the swift-metrics API even if the metrics backend supports it.
modifications: Adds a `FloatingPointCounter` type to allow users to accumulate non-integral metrics backed by a `FloatingPointCounterHandler`. Introduces a default implementation for creating and destroying `FloatingPointCounterHandler`s for metric backends that do not natively support floating point counters. On such backends, `FloatingPointCounter` is backed by a `AccumulatingRoundingFloatingPointCounter` which accumulates floating point values internally and record increments to a wrapped `CounterHandler` after crossing integer boundaries.
result: Users can create `FloatingPointCounter`s to record floating point values and get enhanced behavior for backends that support floating point values.
Motivation:
`Timer.record*` methods are generic to cover all cases of `BinaryInteger` values and converts the passed value into `Int64` before doing time unit conversions and overflow checks.
Modifications:
All methods that accept `BinaryInteger` types and converts to `Int64` now guards against values higher than `Int64.max`
Result:
Users can reliably use the `Timer.record*` APIs with `BinaryInteger` types without concern for unknowing fatal errors.
motivation: highlight the need to address overflow in metric objects that are integer based
changes:
* add section in the readme about addressing woverflow
* fix timer's unit conversion to address potential overflow
motivation: allow middleware libraries better control of metric object lifecycle to reduce potential memory footprint when using metrics libraries that use some kind of registry or cache (eg polling backends)
changes:
* Introduce metric.destroy() to enable lifecycle management
* Add destroy functions to example impl in readme
motivation: use consistent formatting
changes: update generate_linux_tests to match the formatting rules we use: `swiftformat --self insert --patternlet inline --stripunusedargs unnamed-only --comments ignore`
* prepare to release
motivation: the sswg voted to adopt the API. this is to prepare to a release
changes:
* rewrite readme
* add API docs
* add utilitiy scripts and docker setup for CI
* adjust linux tests