Should the SDK API constrain the Readers that can be used?

[MadVikingGod]

Background

Currently, we require that the Readers provided to the WithReader Option be comparable. We check that the two readers we create are comparable, but if a user embeds a Reader in a non-comparable struct WithReader will panic. An example of how to trigger this can be found here.

This type of embedding will probably be used in the prometheus exporter.

Problem Statement

Should we further constrain our option to prevent users from supplying a non-comparable reader? This would likely be run into by exporter developers and hopefully caught by a working example.

Proposed Solution

We could create a ComparableReader interface that we constrain the WithReader with. Here is an example branch.

This would in effect turn the runtime panic into a compile-time error. You wouldn't be able to use a non-comparable Reader with the only option we have.

This would have two drawbacks:

1. This would change the SDK API if done after the alpha is released. We are allowed to, but I would like to minimize this if possible.
2. Because you can't cast Reader -> ComparableReader the output of New*Reader would have to change from Reader.

• Either to a *manualReader, which has usability concerns,
• or to a *ManualReader, note this is exporting ManualReader, which means we need to guard aginst users using a &ManualReader{}

Alternatives

1. Accept the runtime error, and encourage exporter creators to check that it works with the SDK.
2. Remove the comparable constraint on readers.

[MrAlias]

Closing as #3233 looks to have resolved this. The Reader implementation no longer needs to be comparable. Please reopen if this was an error.

[MrAlias]

opentelemetry-go/sdk/metric/config.go

Line 29 in b6a22ab

readers map[Reader][]view.View

[MrAlias]

opentelemetry-go/sdk/metric/pipeline.go

Line 404 in b6a22ab

func newPipelines(res *resource.Resource, readers map[Reader][]view.View) pipelines {