Update dependency apple/swift-collections to from: "1.4.1"#237
Merged
Conversation
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
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 contains the following updates:
from: "1.4.0"→from: "1.4.1"Release Notes
apple/swift-collections (apple/swift-collections)
v1.4.1: Swift Collections 1.4.1Compare Source
This patch release is mostly focusing on evolving the package traits
UnstableContainersPreviewandUnstableHashedContainers, with the following notable fixes and improvements to the stable parts of the package:DequeModuleandOrderedCollectionsmodules.Changes to experimental package traits
The new set and dictionary types enabled by the
UnstableHashedContainerstrait have now resolved several correctness issues in their implementation of insertions. They have also gained some low-hanging performance optimizations. Like before, these types are in "working prototype" phase, and while they have working implementations of basic primitive operations, we haven't done much work validating their performance yet. Feedback from intrepid early adopters would be very welcome.The
UnstableContainersPreviewtrait has gained several new protocols and algorithm implementations, working towards one possible working model of a coherent, ownership-aware container/iteration model.BidirectionalContainerdefines a container that allows iterating over spans backwards, and provides decrement operations on indices -- an analogue of the classicBidirectionalCollectionprotocol.MutableContaineris the ownership-aware analogue ofMutableCollection-- it models a container type that allows its elements to be arbitrarily reordered and mutated/reassigned without changing the shape of the data structure (that is to say, without invalidating any indices).PermutableContaineris an experimental new spinoff ofMutableContainer, focusing on reordering items without allowing arbitrary mutations.RangeReplaceableContaineris a partial, ownership-aware analogue ofRangeReplaceableCollection, providing a full set of insertion/append/removal/consumption operations, with support for fixed-capacity conforming types.DynamicContainerrounds out the range-replacement operations with initializer and capacity reservation requirements that can only be implemented by dynamically sized containers.We now have working reference implementations of lazy
map,reduceandfilteroperations on borrowing iterators, producers and drains, as well acollect(into:)family of methods to supply "greedy" variants, generating items into a container of the user's choice. Importantly, the algorithms tend to be defined on the iterator types, rather than directly on some sequence/container -- going this way has some interesting benefits (explicitness, no confusion between the various flavors or the existingSequencealgorithms), but they also have notable drawbacks (minor design issues with the borrowing iterator protocol, unknowns on how the pattern would apply to container algorithms, etc.).Like before, these are highly experimental, and they will definitely change in dramatic/radical ways on the way to stabilization. Note that there is no project- or team-wide consensus on any of these constructs. I'm publishing them primarily as a crucial reference point, and to gain a level of shared understanding of the actual problems that need to be resolved, and the consequences of the design path we are on.
What's Changed
New Contributors
Full Changelog: apple/swift-collections@1.4.0...1.4.1
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.