Open branchseer opened 4 months ago
I like this concept a lot, but I have a vague memory I had a discussion about this with @ZoeyR a while back and we decided not to do this.
We'll get back to you
I had a discussion with @ZoeyR and we decided that this is a useful feature and we're willing to break open the API for this.
Could you get this in a state where the CI succeeds? Specifically test --no-default-features
, as this tends to fail a lot.
As for the TODOs:
I like writing out things fully, so Context
please
I maintain virtue so feel free to make a PR to that
Let's start with the minimum effort you need to do to get this merged, we can enhance the macros later
Thanks a lot for your proposal!
That's great to hear. Thanks! I'll work on it as soon as I'm back from vacation.
Why
With the current
Decode
/BorrowDecode
, it's impossible to implement them on a type that borrows something other than the input data. A concrete example would be aVec<'bump, T: 'bump>
which is allocated by an arena allocator.How
This PR introduces the following changes:
decode_from_slice_with_ctx<Ctx, D: de::Decode<Ctx>, C: Config>(src: &[u8], config: C, ctx: Ctx)
. In that arenaVec
example, the decode context would be the allocator&Bump
.DecoderImpl
and exposed toDecode
implements viaDecoder::ctx
method.Decode
trait is changed toDecode<C>
, which allows types to implementDecode
only under some specific context. (Vec<'bump, T: 'bump>
would implementDecode<&'bump Bump>
)Decode
is changed to generatingimpl<Ctx> Decode<Ctx> for ...
instead ofimpl Decode for ...
. A container attributedecode_context
is added to allow derivingDecode
with a concrete context type. (for example#[bincode(decode_context = "&'bump Bump")]
)BorrowDecoder
.You can see how these changes work together in
tests/ctx.rs
.I know this is a big change and would break existing
2.0.0
users. But it's stillrc
so I guess it's not too late to discuss it? ;)Alternative Design
Leaves
(Borrow)Decode
untouched, and add(Borrow)DecodeWithContext<C>
.Pros:
(Borrow)Decode
.Con:
TODOs
This PR hasn't been polished to a mergeable state yet. I will do that if the overall design is accepted.
impl<Ctx>
. This would need a separate PR.Decode
allowsCtx
to be either a concrete type or totally unbounded. How about allowingCtx: ...
? Is it useful enough to be implemented?