Before opening a feature request against this repo, consider whether the feature should/could be implemented in the other OpenTelemetry client libraries. If so, please open an issue on opentelemetry-specification first.

Is your feature request related to a problem?

TextMapCarrier requires all implementations to provide both Injector and Extractor behavior from the OpenTelemetry specification. This is unnatural from the C++ perspective and not compatible with some communication frameworks.

Describe the solution you'd like
Separate TextMapCarrier into Injector and Extractor interfaces. Update TextMapPropagator to use different interfaces for the Inject and Extract methods.

Describe alternatives you've considered
Assuming the caller has some container const T t on which they would base a TextMapCarrier implementation, the naive solutions involve either const_casting or copying t. The former creates surface area for correctness issues while the latter incurs a performance penalty.

The TextMapCarrier implementation could provide Set as a no-op which avoids the performance penalty, but still carries correctness risks. A misuse of this solution could be expensive to identify (especially given that Set is marked noexcept).

The TextMapCarrier implementation could use a copy-on-write container. This solution has additional complexity, either requiring the client to provide such a container or requiring the client to understand the additional constraints of an OpenTelemetry-provided solution.

Separation of interfaces seems to provide the best trade-off, including:

• Allowing the consumer to more precisely express intent which is enforceable by the compiler;
• Creating a simple API with idiomatic basis in the C++ standard (and explicit allowance in the OpenTelemetry specification); and
• Incurring the lowest performance penalty for the required scope.