Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

core: Consider changing Value to dispatch primitives with an enum rather than trait objects #925

Open
davidbarsky opened this issue Aug 13, 2020 · 4 comments
Labels
crate/core Related to the `tracing-core` crate needs/design Additional design discussion is required.

Comments

@davidbarsky
Copy link
Member

davidbarsky commented Aug 13, 2020

Feature Request

Crates

  • tracing-core

Motivation

As detailed in #922, we have the opportunity to make breaking changes in tracing-core with the release of Tokio 0.3.

Proposal

While I believe that @hawkw and @carllerche have talked more about this, @hawkw shared a sketch of a possible approach.

@davidbarsky davidbarsky added crate/core Related to the `tracing-core` crate needs/design Additional design discussion is required. labels Aug 13, 2020
@davidbarsky davidbarsky changed the title core: Consider changing Value to dispatch primitives with an enum rather than trait objects core: Consider changing Value to dispatch primitives with an enum rather than trait objects Aug 13, 2020
@KodrAus
Copy link
Collaborator

KodrAus commented Aug 14, 2020

I like the wrapper-struct approach like @hawkw's sketch. I don't want to become the "well, actually in log..." guy, but that's the approach I've taken there, which has let us wrap up both a enum of primitives and trait objects together along with quite a deep compatibility layer that the public API doesn't have to know about.

@hawkw
Copy link
Member

hawkw commented Aug 14, 2020

I like the wrapper-struct approach like @hawkw's sketch. I don't want to become the "well, actually in log..." guy, but that's the approach I've taken there, which has let us wrap up both a enum of primitives and trait objects together along with quite a deep compatibility layer that the public API doesn't have to know about.

Yup, that was a big part of the inspiration for this change. :)

@KodrAus
Copy link
Collaborator

KodrAus commented Aug 16, 2020

Ah gotcha! 😄

As a future possibility, if you haven’t checked it out already you could also find some inspiration in the way std::fmt erases values by transmuting a &T: Trait into a (&Opaque, fn(&Opaque) pair instead of lots of enum variants. It might make it possible to save some space and boilerplate internally.

@hawkw
Copy link
Member

hawkw commented Aug 17, 2020

As a future possibility, if you haven’t checked it out already you could also find some inspiration in the way std::fmt erases values by transmuting a &T: Trait into a (&Opaque, fn(&Opaque) pair instead of lots of enum variants. It might make it possible to save some space and boilerplate internally.

Hmm, that's interesting and maybe worth looking into in the future as an optimization! I considered a safe version of this that relies on creating a closure that calls downcast_ref on an Any, much earlier in tracing's development, but that introduces a lot of overhead, which this maybe avoids...might be worth trying at some point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
crate/core Related to the `tracing-core` crate needs/design Additional design discussion is required.
Projects
None yet
Development

No branches or pull requests

3 participants