Closed mitsuhiko closed 2 years ago
Interestingly this also brings up the point that the descriptor will have to move from the seq/map sink into the main sink. One consequence of this is that expecting
could go away it becomes possible to use the type name from the descriptor directly.
This is a followup to #6. At the moment
MapSink
andSeqSink
primarily exist because before the introduction of theSinkHandle
it was impossible for aSink
to hold state. The solution inherited from miniserde was to create a map/seq sink whenmap
/seq
was called which in turn creates the boxed allocation and writes into the slot on finalization.Now that we can hold a boxed sink directly in the
SinkHandle
this indirection is not helpful any more. More than that, this indirection causes one new challenge which is thatMapSink
has its lifetime bound to the outerSink
which makes it hard to compose deserializers. For instance for flattening (#9) it would be nice to be able to inquire another sink about if its interested in a key. This basically requires that a sink also starts another sink so it can drive that one as well. With the currentMapSink
indirection this is not possible due to lifetimes.So the plan could be to inline the logic for the map and seq sinks directly onto the main sink. Example for
BTreeMap
:For structs one could then introduce a
value_for_key
method which could be reached through to implement flattening. In the following example theStructSink
holds an inner struct which should be flattened: