Add Archive::unpack_mapped#449
Open
RemiBardon wants to merge 2 commits into
Open
Conversation
This allows mapping paths when unpacking an archive.
This allows mapping paths while extracting, if [composefs#448] gets merged. See the above pull request for rationale regarding this addition. [composefs#448]: composefs#448
Author
|
(FYI I ended up not needing this as I need to iterate over entries myself. You can close this PR if you feel like it’d be too intrusive.) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
(Follow-up to #448, merge first.)
This allows mapping paths while extracting, if #448 gets merged. See this other PR for rationale.
We can discuss implementation, as I’m aware I introduced some genericity which might affect performance / binary size / compile time. There are no benchmarks so I couldn’t know if my changes had an impact. It should not since most people will never use
unpack_mappedand_unpackwill get monomorphized to the exact same function as before, with the compiler likely optimizing away the newly added line as it’s a no-op. And in the rare case where one needsunpack_mapped, they’d likely have a single call site sounpack_mappedwouldn’t bloat the binary. But that’s just my opinion, I’d get it if you want to use dynamic dispatch instead.Oh and also feel free to change the method name, I had no inspiration 🙆♂️