Expose tracing_core::span::Current from tracing

[anp]

Feature Request

Motivation

Implement a subscriber only using types exported from the tracing crate without having to reference tracing-core directly.

Proposal

Re-export under tracing::span::Current.

Alternatives

Probably, not sure though.

[hawkw]

I think we can definitely do this. Any particular motivation for not depending on tracing-core explicitly, or just simplifying imports & dependencies?

[anp]

Just simplifying imports & dependencies. If I'm already consuming everything else from tracing-core via tracing, it's a weird cliff in the API to add just one item. Alternatively, exposing it via tracing-subscriber could make sense? While it's not guaranteed that every implementor of tracing_core::Subscriber would consume tracing-subscriber, it would be true in my case at least.

[hawkw]

In general, I think a subscriber being implemented in the same crate as code that's implemented using tracing is not the most common case...generally, I expect subscriber implementations to be standalone crates that either depend on tracing-core or tracing-subscriber. If you're using tracing-subscriber, you're probably implementing the Layer trait rather than the Subscriber trait, and in that case, you don't need the span::Current type.

With that said, I'm totally fine with adding the re-export. It's just that up until this point there wasn't really any demand for it & I wanted to keep each crate's API surface small to avoid information overload.

[anp]

Right, this all makes sense. I think my confusion would have been better prevented by better subscriber docs (#505 (comment)), so I’ll close this without a clear motivator and since I probably won’t need to reference Current after all.