Make BytesMut::try_unsplit method public
#746
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is identical diff-wise to #513 with some additional justification that hopefully leads to a merge.
There are currently two open discussions. One is on whether the
Bytestype should have atry_unsplitmethod and another one is on whether theBytesMuttype should have atry_unsplitmethod. The former is being discussed in #287 and the latter in #702.The discussion on
Bytesis complicated by the fact that the type does not currently haveunsplitfunctionality. Therefore introducing it for that type is something to be considered deeply since it expands the surface area and comes with maintainability and backwards compatibility concerns.This PR is NOT related to the
Bytestype or that discussion.This PR only changes
BytesMutwhich already offers anunsplitmethod in its public API whose specification (i.e doc comment) is:This means that at least for
BytesMutthe unsplit functionality is here to stay, at least until a new major version is released. Also, the specification ofunsplitalready encodes this idea of "it will try to do X, otherwise fallback to Y" and so it is reasonable to expect that any future changes in the codebase will have to maintain this kind of conditional implementation where at some point theunsplitfunction makes a decision.Under that view, all this PR is doing is offering what
unsplitalready does but without the "otherwise..." part, leaving it up to the user to select what happens next. This shouldn't present any backward compatibility/new surface concerns since no matter howunsplitevolves we can always take the logic until theif possible_to_merge { .. }bit and expose it undertry_unsplit