This issue refers the current implementation that includes post go1.16beta1 fixes:

go version devel +95ce805d14 Thu Dec 31 02:24:55 2020 +0000 linux/amd64

Proposal: #37112
API Audit: #43407

I've found that using implicit -inf/+inf boundaries with the runtime/metrics.Float64Histogram API is a bit awkward (compared to using explicit boundaries). Implicit boundaries:

• Require extra logic for the caller since the start/end boundaries need to be interpreted differently
• The first bucket (-inf) is usually nonsensical/wasted and ignored (negative allocation size, negative duration).

I think it would be much better making the boundaries explicit:

• Much simpler for API callers to interpret since there is only a single rule and no need to synthesize bucket ranges
• Metrics can choose the boundaries that make the most sense (math.Inf(-1) is a valid floating point number). Eg, it is impossible to allocate -10 bytes - using [1, 9) or [0, 9) for the first bucket makes more sense.

In practice, the total number of float64s could be the same since the first bucket can usually be dropped. Eg:

Assuming the following counts / buckets:

• [0, 10): 1
• [10, 20): 2
• [20, +inf): 3

Current implicit encoding:

• Counts: 0, 1, 2, 3
• Buckets: 0, 10, 20

Proposed explicit encoding:

• Counts: 1, 2, 3
• Buckets: 0, 10, 20, +inf

Even if there is a reason to keep the unused -inf bucket, making the boundaries explicit provides more future flexibility and makes it easier for callers.

For comparison, the current API is documented as:

// count[0] is the weight of the range (-inf, bucket[0])
// count[n] is the weight of the range [bucket[n], bucket[n+1]), for 0 < n < N-1
// count[N-1] is the weight of the range [bucket[N-1], inf)

Note: this is actually incorrect, it should be [bucket[n-1], bucket[n]), for 0 < n < N-1.

The explicit boundary API would be:

// count[n] is the weight of the range [bucket[n], bucket[n+1]), for 0 <= n < N

Simplifying the documentation crudely indicates using explicit boundaries provides a cleaner API.

Cc @mknyszek

Sorry about the report late in the cycle, but I think this would be a much better API for the future and it's a simple fix now.