Closed paolobarbolini closed 4 months ago
Would it make more sense to move this check to
advance_unchecked
?
I'm not quite sure how to structure this because the thing with advance_unchecked
is that it gets called by split_to
and split_off
. These functions expect advance_unchecked
to actually advance the position, otherwise they would end up with the two instances of BytesMut
having overlapping ranges.
The conflict with split_to
and split_off
is a good reason to not put it in advance_unchecked
.
Good idea. Fixed!
This change broke our usage of BytesMut
in s2n-quic, where we have a similar expectation:
These functions expect
advance_unchecked
to actually advance the position, otherwise they would end up with the two instances ofBytesMut
having overlapping ranges.
In our case, we expect that advance
actually reduces the overall capacity of the chunk. There's also no efficient way to work around this, since the only option is to call split_to
and discard the result.
That's unfortunate, we may have to revert this change. Can you open a bug report with details about this regression?
Opened #725
While thinking about usage of
BytesMut
in my own code I've realized sometimes the following pattern (explained by the following pseudocode) is encountered:In this particular example it would be more efficient to
buf.clear()
whenconsumed == buf.len()
, instead of callingadvance
and eventually ending-up going through the allocation machinery.This PR makes
advance
do it automatically for cases in which it's safe to do (which is why I didn't put it insideadvance_unchecked
). I'm not sure theBuf
API allows it, the only thing I've found is#[must_use = "consider BytesMut::advance(len()) if you don't need the other half"]
onBytesMut::split()
.