consider TracerSpan assoc type -> Span

[ktoso]

Something @fabianfett requested we give another look at.

Resolves #110 but we should discuss this more -- it comes with a confusing tradeoff for implementers of spans I suppose. Please discuss. I'm on the fence, it is nice to not have Tracer.TracerSpan but the tradeoff is some potential confusion hmmm

Motivation:

Users who use generic Tracer end up having to spell Tracer.TracerSpan.

We could help those situations by renaming the associated type. However at the cost of causing name conflicts where the Span implementation must qualify that it is implementing Tracing.Span.

This may or may not be worth it -- discuss.

Modifications:

associatedtype TracerSpan: Span -> associatedtype Span: Tracing.Span

[fabianfett]

@ktoso can you give an example for this?

We could help those situations by renaming the associated type. However at the cost of causing name conflicts where the Span implementation must qualify that it is implementing Tracing.Span.

[fabianfett]

Why do we need to be explicit here? Where is the conflict coming from?

[ktoso]

Yeah here I can likely just do Span, that's right.

In a TracerProtocol we sometimes had to be explicit.

I can give this a cleanup pass

[ktoso]

This is one annoying spot, people MUST write Tracing.Span here

[stevapple]

What about swapping TracerSpan and Span?

[ktoso]

Maybe, what do @tomerd @fabianfett @Lukasa think?

[fabianfett]

I don't find this to annoying. The tough part here is really only on the tracer implementers. TracerSpan is on all the users. If we want to keep the pain small, the first group should deal with it, not the second.

[ktoso]

Yeah it's on implementors to do the dance, I don't mind either I guess.

[stevapple]

I would prefer TracerSpan to [Tracing.]Span here. Swift’s name lookup is still tricky now (see https://forums.swift.org/t/pitch-fully-qualified-name-syntax/28482 for the context). If the client happens to have a top-level Tracing type, it will completely lose access to Tracing.Span. Not to say TracerSpan is shorter by two ASCII characters:)

[fabianfett]

I'm not sure I agree with the argument here. Using Tracing.Span is an escape hatch, when you define the Span type inside a Tracer. If you implement a Tracer you must import Tracing. If you then introduce a local type Tracing, you are screwed anyway. Rule number one of Swift namespaces: Don't name a type like a module you import.

If we look at it from the perspective of a tracing user, it is much nicer to write Span everywhere instead of using TracerSpan. The argument you make, that Swift namespace lookup sometimes isn't working correctly (by breaking Rule number one of Swift namespaces: Don't name a type like a module you import) does apply to Span as it does to TracerSpan.

[stevapple]

A typical tracing user doesn’t use either [Tracing.]Span or Tracer.Span, as the Tracer.Span type can be inferred from Tracer.startSpan.

Both Span and TracerSpan can cause some confusion with Tracer.Span, but the fact that Span is ambiguous, despite being possible to work around and comfort the compiler, will inevitably troubles code review.

Given that the type name is not used very often, I would still suggest the longer but less error-prone TracerSpan.

[fabianfett]

Love the change!

[ktoso]

Yeah I think this will be fine. I'll merge tomorrow probably tho

[ktoso]

Let's give this a shot -- thank you for the discussion @stevapple and @fabianfett, I think Fabian made a good point and we can try this out in the next beta. I think it'll work out fine.