Closed KodrAus closed 2 years ago
If we wanted to re-introduce the Fill
API which would be needed to do zero-cost bridging between log
and tracing
then this Visitor
type could be used in place of that Slot
, which is really just a value::Visitor
.
I've updated the proposed trait based on the design that ended up coming out of value-bag
in https://github.com/sval-rs/value-bag/pull/16
All it really does is add a 'v
lifetime to the value::Visitor
trait, so that it becomes possible to capture borrowed strings across calls if you need. This 'v
lifetime will be the same as the 'kvs
in Visitor::visit_pair<'kvs>
so it ends up being threaded all the way through from a borrow of the Source
to visitors of the Value
s.
Now that we've got 0.4.14
out we can make progress on this :tada:
@KodrAus what parts are missing to implement this?
Hey @Thomasdezeeuw :wave:
The implementation work was actually all there, so I've opened up #467 that surfaces the visitor API.
Motivation
Users want to be able to visit simple primitives captured in
kv::Value
s but currently resort to chaining calls like:This is flaky and not fun to write. The goal of the current design is that if you're serializing values you probably already have a serialization framework handy (either
std::fmt
,serde
, orsval
) that you'll want to use.There are reasons to want to visit values without pulling one of these in though. For example, https://github.com/Thomasdezeeuw/std-logger/pull/29#discussion_r553903486 wants to write custom formatting logic to make use of
IoSlice
s, and others don't want the additional mental overhead in learning another framework.Proposal
Add a simple zero-dependency visit API for
log::kv::Value
that can be used instead of chainingto_*
methods or learning a full serialization framework. It intentionally won't support complex values, but should be enough for simple cases to get off the ground with. A new trait,kv::value::Visitor
will be added with the following methods:with a default implementation looking something like:
A
Value
can be visited using an inherentvisit
method:Other methods can be overridden to customize their behavior.
Migrating from
value::Visitor
tosval
orserde
If callers want to switch from
value::Visitor
tosval
orserde
to support more complex serialization needs, the change will be from callingValue::visit
to either<Value as sval::Value>::stream
or<Value as serde::Serialize>::serialize
.Questions
Why not add these to
source::Visitor
?The
source::Visitor
trait is centred aroundvisit_pair
, which lets us build higher-level methods on top, likeget
. If we add other methods tosource::Visitor
it may become confusing how the trait should be implemented to support these higher-level methods.Why does
visit_any
take aValue
?The
Value
type is a carrier for a bunch of trait implementations,fmt::Debug
,fmt::Display
, and possiblysval::Value
, andserde::Serialize
. By passing in aValue
here we give the caller flexibility to decide what trait they want to use without adding a lot of complexity to thevalue::Visitor
trait.