The Sequence trait is built around a callback which accepts a [&dyn Encodable] slice as an argument.
This necessitates what are currently some special case hacks when dealing with intermediate values used for encoding which need to wrap a reference to a field. There are currently ContextSpecificRef and OptionalRef to handle encoding context-specific and OPTIONAL fields.
A nicer alternative would be to have a single solution that works everywhere, rather than introducing special case types for handling references as this comes up. Some potential solutions:
- Introduce an owned shim type which wraps a reference and impls
EncodeValue, e.g. EncodeRef. This feels like a bit of a hack, but less of a special case one than things like ContextSpecificRef and OptionalRef. In fact, the latter could be type aliases composed in terms of the former.
- Change the
EncodeValue blanket impl to operate on &T where T: EncodeValue. This is a bit tricky because there's already a blanket impl of EncodeValue for sequence types, so that would need a different solution. However, as Sequence is already a derived trait, it would be possible to add a derived EncodeValue shim which uses a helper method to easily encode any Sequence.
My inclination is to try the first immediately as that one's easy enough, then experiment with the second to see if it's feasible.
The
Sequencetrait is built around a callback which accepts a[&dyn Encodable]slice as an argument.This necessitates what are currently some special case hacks when dealing with intermediate values used for encoding which need to wrap a reference to a field. There are currently
ContextSpecificRefandOptionalRefto handle encoding context-specific andOPTIONALfields.A nicer alternative would be to have a single solution that works everywhere, rather than introducing special case types for handling references as this comes up. Some potential solutions:
EncodeValue, e.g.EncodeRef. This feels like a bit of a hack, but less of a special case one than things likeContextSpecificRefandOptionalRef. In fact, the latter could be type aliases composed in terms of the former.EncodeValueblanket impl to operate on&TwhereT: EncodeValue. This is a bit tricky because there's already a blanket impl ofEncodeValuefor sequence types, so that would need a different solution. However, asSequenceis already a derived trait, it would be possible to add a derivedEncodeValueshim which uses a helper method to easily encode anySequence.My inclination is to try the first immediately as that one's easy enough, then experiment with the second to see if it's feasible.