There MUST NOT be any API for creating an instrument other than with a Meter

[MrAlias]

Currently the OpenTelemetry specification states:

There MUST NOT be any API for creating a Counter other than with a Meter

There MUST NOT be any API for creating an Asynchronous Counter other than with a Meter

There MUST NOT be any API for creating a Histogram other than with a Meter

There MUST NOT be any API for creating an Asynchronous Gauge other than with a Meter

There MUST NOT be any API for creating an UpDownCounter other than with a Meter

There MUST NOT be any API for creating an Asynchronous UpDownCounter other than with a Meter

The opentelemetry-go project currently provides the asyncint64.InstrumentProvider, asyncfloat64.InstrumentProvider, syncint64.InstrumentProvider, and syncfloat64.InstrumentProvider APIs to create these instruments.

[MadVikingGod]

Has there been any recorded feedback that the current API is non-compliant?

My issue with this interpretation is that it is stricter than other SDKs have taken. Java, python, and probably others use a builder pattern, where the meter's API returns an intermediate object that can be used to create the actual instrument.

We decided on the current format in march (#2526), what has materially changed to churn like this?

[MrAlias]

Has there been any recorded feedback that the current API is non-compliant?

This issue acts as a source of recorded feedback, it is stating the non-compliance of our implementation. Additionally, #2653 and #2653 (comment)

My issue with this interpretation is that it is stricter than other SDKs have taken. Java, python, and probably others use a builder pattern, where the meter's API returns an intermediate object that can be used to create the actual instrument.

To be clear, Java indeed does use a builder pattern, though Python does not. Also, javascript does not (I'm pretty sure .NET does, but cannot find the link as I get lost looking at that repo).

I agree that the builder pattern may not adheres to the normative requirements of the specification, and that these other language implementation are out of compliance. This was a reason I did not suggest moving to a builder pattern in this issue. That said, I would be open to exploring the builder pattern if there is evidence this was intended to be allowed by the specification (though this would run into style issues with our expected options pattern).

To be clear our instrument provider approach is not equivalent to the builder pattern other languages provide. The builder pattern is an alternative approach to building up the configuration of an instrument during its construction. This is both a common pattern for those languages and can be for Go. Our current approach provides configuration with option parameters, the instrument providers are solely intended as APIs to construct instruments from (as stated in the linked issue). This being the sole intention of the instrument providers, means they are an additional interface we export for users to create instruments other than with a Meter. Hence, they directly violate the specification requirement.