Leverage 'INumber' interfaces for 'Instrument<T>' in .NET7

[julealgon]

The current Instrument<T> and its inheritors, like Counter<T>, rely on runtime checks to ensure that only a subset of number structures are used as the T value (like int, long, float, decimal, etc).

I had to create some abstractions around Counter<T> in our application and ran into an issue because I needed to detect whether the delta measurement was "positive or negative" and also had to invert the value when it was negative. Since it is typed to T, this becomes convoluted to do, in particular the value inversion bit.

To avoid ramping up complexity, I decided against making my own abstraction generic and went with a forced T=int constraint on my abstraction, as our current requirement only involves int counters.

I think these classes could easily leverage the math/numeric interfaces introduced in .NET7 to properly constrain the generic type in a way that still allows for math-based computations and avoids all the runtime type checking.

Is this being considered?

EDIT: Found this question being asked by @terrajobst here, but it wasn't answered in the issue:

• Support Metrics UpDownCounter instrument #63648 (comment)

Restricting the list of possible types based in the OTel spec to me seems ill-advised. This API can be used in situations outside of OTel so it is totally fine if it is more flexible than the OTel protocol definitions. This is already the case today with the instrument names, which can be "anything" in .NET, but have a regex limitation in OTel (i.e. no spaces are allowed).

Behavior for using an instrument with a type not specified in the OTel protocol should be similar to what happens with other nonconforming parts today: the instrument should be skipped during export with a internal warning message saying it is not compatible with Open Telemetry standards.

[huoyaoyuan]

I believe it's out-of-scope for .NET 7 for similar scenarios. Currently the type system lacks feature to use type parameter in more constrained generics.

[julealgon]

Currently the type system lacks feature to use type parameter in more constrained generics.

Can you elaborate a bit more on this? I'm not exactly sure what you mean there.

[tannergooding]

Given M<T>() { } there is no mechanism through which you can then call a method N<T>() where T : INumber<T> { }. Additionally, since changing an existing generic constraint is a breaking change this makes the N inaccessible to existing APIs.