Toby Lawrence

👋🏻 At a high level, your assessment is accurate: we buffer all individual histogram measurements until something drains them. This indeed represents an unbounded queue, effectively. We used to have...

Taking a cursory glance, this is definitely more work than I'd be comfortable taking on personally. I'd accept a PR adding this functionality and can try and offer some guidance...

Nobody is working on this as far as I know, so it's all yours. :)

## Possible answer/solution: warn people about it. It could be sufficient to warn people that when using metrics handles, they cannot or should not drop idle metrics. For use cases...

## Possible answer/solution: provide a way to register handles in a strong or weak fashion. As a play on the strong versus weak pointers of `Arc`, we could potentially provide...

## Possible answer/solution: allow handles to re-register. Given that the recorder is exposed such that there's always a `&'static` reference to it, one approach could be to use the strong/weak...

Sorry that you've been having trouble using the new handle-based API in 0.18. At a high-level, there's not much that changes from the perspective of the recorder: - all `describe_*`...

Answering out of order: > Another, but related, the problem is reusing Registry for custom Key. Now Registry's methods accept metrics::Key instead of custom key implementation. So, instead of just...

> The main disadvantage of the suggested approach is that the metric set is unbound: all metrics produced by user-written code should use the same approach, not only provided by...

Just to take a step back... My assertion here is that between 0.17 and 0.18, there wasn't a meaningful change to performance/efficiency for callers who just used `counter!("my_metric_name", 1, "label"...