You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Introduce top level withSpan; reclaim Tracer for protocol
**Motivation:**
The TracerProtocol naming was annoyingly problematic and turns out we
can and should actually move the withSpan APIs as top level functions
which is typical Swift practice for such "global functionality".
This way we can `withSpan() {}` with less noise, and also gain back the
Tracer protocol name.
Creating an instrument means adopting the `InstrumentProtocol` protocol (or `TracerProtocol` in case you develop a tracer).
542
-
`InstrumentProtocol` is part of the `Instrumentation` library & `Tracing` contains the `TracerProtocol` protocol.
541
+
Creating an instrument means adopting the `InstrumentProtocol` protocol (or `Tracer` in case you develop a tracer).
542
+
`InstrumentProtocol` is part of the `Instrumentation` library & `Tracing` contains the `Tracer` protocol.
543
543
544
544
`InstrumentProtocol` has two requirements:
545
545
@@ -556,7 +556,7 @@ how to retrieve values from the `LoggingContext` and how to set values on it.
556
556
557
557
When creating a tracer you need to create two types:
558
558
559
-
1. Your tracer conforming to `TracerProtocol`
559
+
1. Your tracer conforming to `Tracer`
560
560
2. A span class conforming to `Span`
561
561
562
562
> The `Span` conforms to the standard rules defined in [OpenTelemetry](https://github.com/open-telemetry/opentelemetry-specification/blob/v0.7.0/specification/trace/api.md#span), so if unsure about usage patterns, you can refer to this specification and examples referring to it.
0 commit comments