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
Currently the Tracer protocol has the startSpan requirement. The return of startSpan is a Span which is a protocol. In other words we return an existential here. Instead we might want to consider making the Span an associated type and returning the concrete type:
publicprotocolTracer:Instrument{
associatedType Span: SpanProtocol // the current Span protocol maybe needs a rename to SpanProtocol for this?
func startSpan(
_ operationName:String,
baggage:Baggage,
ofKind kind:SpanKind,
at time:DispatchWallTime,
function:String,
file fileID:String,
line:UInt)->Spanfunc forceFlush()}
I can see no reasons, why a Tracer would return Spans of different types. If that was a requirement adopters could work around this, by using internal enums.
Result
We preserve more type information if we work with a concrete Tracer.
The text was updated successfully, but these errors were encountered:
Sounds good to me 👍 The rename to SpanProtocol also sounds good and actually fits nicely with @ktoso's rename of Tracer and Instrument to *Protocol: #69
Currently the
Tracer
protocol has thestartSpan
requirement. The return ofstartSpan
is aSpan
which is a protocol. In other words we return an existential here. Instead we might want to consider making the Span an associated type and returning the concrete type:I can see no reasons, why a Tracer would return Spans of different types. If that was a requirement adopters could work around this, by using internal enums.
Result
We preserve more type information if we work with a concrete Tracer.
The text was updated successfully, but these errors were encountered: